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1.0 GENERAL 
1.1 PREEACE IO REVISION J_ (REVISED 26 JULY_1984) 


Aporoved SIS DAPs Incorporated In this revision are: 


$4446 - Revised C180 Common Parameter List Format (John Barney) 
- (Major changes to section 5.2) 

$4658 - Add Deck Classes A and B (Pete Warburton) 

$4753 - Correct Dialog Parameter (Alan McMahan) | 

$4775 =- Change Product 79 for BASIC (Bruce Kenner) 


162 REVIEWING AND UPDATING THIS DOCUMENT 


The C3I89 SIS has been through a number of review cycles and has been 
Formally approved by the C180 Baseline Change Control Board (BCCB). 
It is thus considered fairly solid. 


Howevers it is recognized that the SIS is a living document with a 
continual need for updating.e. Please follow the following guidelines 
in reviewing and updating this document: 


1. Limit comments or updates te question of Inaccuracy,s, lack of 
completeness» or necessary technical change. Avoid questions 
of personal preference, 


car For relatively minor problems or questions resulting from a 
normal reviews, a normal DCS comment is appropriate. it is the 
responsibility of the appropriate author(s) to resolve the 
commente 


3 For more major updates that may be somewhat controversials a 
stand-alone DAP Is appropriate. This allows a thorough review 
of the Issues Involved. When approveds the DAP will be | 
incluced in the next SIS update. The SIS referee or editor 
should be informed of any plans to submit such a DAP and the 
DAP should be in the form of a proposed SIS update. 


4, There will be occasstlonal "minor review cycles” of the SIS to 
Incorporate minor changes and previously approved DAPs. 
Authors may make minor changes to their sections at this time 
for review and aporoval. 
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1.3 CHARTER 
The purpose of this standard is to ensure a uniformity 
across the operating system and product set that will make 
the total system more easily usable and human engineered. 
Letded SCOPE 


This standard covers product-to-products product-to~users 
system-to-users and product-to-operating system interfaces. 


Any external Interface which is not defined by an industry 
standard may be defined in the System Interface Standard. 
In order to achieve a uniformity across the product sets 
certain internal Interfaces shall be Inciuded In this 
standard, e.9. calling sequences. 
The product set Includes: 

The Comollers, Interpreterss and Assemblers 

Data Management Products 

Utilities 

Source Code Malntenance 
The operating system includes: 

Basic operating system (monitors I/0 driverss system 

Startups ooerator communications permanent file 

managers etc). 

Loader 

Record Manager 

Command Language 

Networks and Interactive Product 

On-Line Maintenance Software 


The "system”™ Includes: 


The operating system 


i323 
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The sroduct seat 


specific goals of the System Interface Standard are: 
Consistency within and across the system. 

Human engineered for user. 

Achievable within CYBER 180 timeframe, 

Good performance, 


External interfaces ike CY170 where this does not 
conflict with a» bs c and d above. 


There must b2 more than trivial gain In aspects of human 
engineering to cause deviation from CY170 external 
interfaces, 
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2e€ INPUT 


This section describes the standard and conventions for 
Input to products. Input standard is defined for System 
Command Languages Control Statements, source file 
organization and contents. 


2el SYSTEM _ COMMAND LANGUAGE 


The System Comnand Language is the set of language rules 
and conventions to be followed by any software product 
that presents a user Interface (which Is not defined by an 
industry standard). It is documented in the NOS/VE ERS 
{BCS documents ARH3609» ARH3610). For examples commands 
to call products» and operator commands wil! conform to 
this language definition. It is a requirement that all 
products use the standard command language routines to 
process system command language statements (such as 
product cal! commands or product directives). The intent 
here is that products do not duplicate code or functions 
already provided by standard command language routines. 
See NOS/VE ERS (AQH3610) for a description of these 
routines. 


202 PRODUCT CALL COMMAND’ 


This standard specifies the parameters which can be used 
in commands that call CYBER 180 products. The syntax of 
the command is documented in the NOS/VE ERS. 


2e2el APPLICABILITY 


This section soecifies ali parameter namess descriptions 
and defaults of parameters on a command that calls a 
product. Requirements for use of the parameters are: 


° If a product offers a capability which is the same as 
one defined in this standards then the specification 
in this standard must be used, 


* A product Is not permitted to use a parameter defined 
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by the standard for a purpose other than that 
specified by the standard. 


* A product need not implement all the parameters or all 
the parts of a paramater in this standard. 


* New parameter names or options must first be approved 
as additions to this standard. 


* A product nay support as many aliases as defined for 
the parameter. However, if a product provides a 
function described by the parameter In this standards 
the described parameter name and its allases must be 
supported by the product as a minimum. 


Some guidelines for proposing new parameter names and/or 
optiens are: 


1. Use a new option of an existing parameter rather than 
anew paraneter name if the capability is an extension 
of an already defined parameter (example: use D#DS5 
instead of Inventing a new parameter DS for debug 
statements. 


2. For related parametersy use allases that emphasize the 
relationship (example: LQ to relate listing options to 
the list file, L). 


20222 TERMINOLOGY 


Default: The value used for a parameter when the parameter 
does not apoear In a command. Section 4.3 on installation 
parameters Indicates which parameter defaults are 
installation changeablee The defaults specified In 
section 2e2e%.2 are those expected to be most often used» 


20203 SYNTAX 


The syntax of the command is defined in the NOS/VE ERS. 


If a parameter is omitteds default values are used. Use 
of <oarameter name = OFF>> results in turning off a single 
option parameter or boolaan single specified vaiue 
parameter. Usa of <parameter name> = NONE indicates that 
a specified value is not supplied for a multiple vatue or 
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multiptie option parameter (for examples 0 = NONE causes 
none of the fist options to be selected). 


When the parameter value is a file names the file name 
$NULL should be used to negate that file (for exampley 
Be$NULL causes the product not to produce a binary object 
code file). NULL is a reserved File namee A read will 
respond with an end-of-information. $NULL Is an infinite 
sink for writes. 


The following algorithm is applied to parameters: 
1. Initially, all value options for this parameter are 
considered deselected (j.e. there are no initial 


values). 


Ze Oniy the option(s) specified in the value fist are 
then selected, 


The <name> used on the command to calf a product can be 
either an alias or a long form as follows: 


Alias Long Form Description 

APL . a programming language 

BASIC beginner's all-purpose symbolic 
instruction code 

Cc The language C 

COBOL common business oriented language 

CYBIL Cyber implementation language 

EDIF EDITLFILE Edit Screen (for raw text) 

EDIL ENITLLIBRARY Edit Screen (for Source Code 
Utitity libraries) 

FMU file management utility 

FTN FORTRAN formula transtation 

LISP fist processor 

PASCAL PASCAL (wirth) 


PLI | programming language I 
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QU query update 

SCU source code utility 
SORT sort 

MERGE merge 

Vx UNIX system emulator 


2e204 PARAMETER 


Occurrence of any parameter more than ence in a contro! 
statement is an e@rrore 


2e2e%e1 Positional Urdecing of Product Set _ Parameters 


Product set menbers providing the Is Bs and L parameters 
must support the following positional ordering on a 
non-keyword call. There is ne guaranteed common ordering 
of other parameters to a product set member except what 
might be documented In the reference manual for that 
procuct. 


de. INPUT 
Ze BINARY (normally the main desired output of a compiler) 
3. LIST 


2e2e%-2 Types_of Parameters 


See the Command Interface (Part I) of the NOS/VE ERS for a 
description of the file reference, which is the syntax to 
be used for specifying a file name as a parameter value. 
If no position is specifieds the product will reposition 
the fille befor2 use as follows? 


a) for a file named $INPUTs no repositioning will 
take place If the file Is at beginning of 
Informations at end of informations or at a 
partition boundary. Otherwise, it will be 
repositioned to end of partition before use. 
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b) for a File named SOUTPUT»s the product will do no 
repositioning before use. 


c) for all other files» the products will reposition 
to beginning of information before use» 


Example: Jf a call to SCU has been made to write three 
source decks to COMPILE (the first FIN»s the second CYBIL» 
the third FIN) and they are to be compiled with the object 
code placed on file LGOs the $ASIS positioning must be 
specified on the second and third compilations since 
default positioning is rewind. 


FTN TaCIMPILE 
CYBIL Te#COMPILE. SASTSsBelLGO.$ASTSsL#S0UTPUT 
FIN T2COMPILE » SASTSsBELGOeSASISsL=SOUTPUT 
There are four kinds of parameters: 
{1) Single Specified Vatue 


This is a parameter for which the user must specify a 
values such as a file reference or a boolean as in the 
form: 


Keyword = <boolean> 

where: 

<boolean> 3:3: = <true> 1 <false> 
<true> t: = TRUE ! YES ?! ON 
<faise> 3:3: = FALSE ! NO ! OFF 


For the sake of consistency the values ON and OFF will be 
used Jn this document. Products may choose any of the 
values for “true> and <faise> desired and describe the 
choices as such in the product documentation. The 
operating system will accept the vaflues for <true> and for 
<false> equivalently when the standard command language 
routines for the control statement processing are used. 

As a results users will be able to enter any of the vatues 
for <true> or for <false> without regard for what values a 
product has chosen to document. 


(2) Multiple Soecified Value 


This is a parameter for which more than one vaiue (such as 
file references) may be specified. The form 
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<parameter-nane = NONE>D will be used to indicate that none 
of the available options for a parameter are desired. 


(3) Single Option 

This is a parameter for which the user specifies 
<option> = ON 

(4) Multipte Botton 


This is a paraneter for which the user may specify the 
names of more than one option. 


Fer multiple soecified value parameters the value tist 
syntax is as described in the NOS 180 ERS» Part I section 
“Parameter Lists and Types". <A value list consists of a 
series of value sets separated by one or more spaces or by 
a Single comma. When more than one value set is 
specifieds the list must be enclosed in parentheses. A 
value set consists of a series of values separated by one 
or more spaces or by a single comma. When more than one 
value is specified the set must be enclosed in 
parentheses. The rule is that an outermost pair of 
parentheses belong to a value fist and inner pairs of 
parentheses belong to value set. 


The form <parameter name = NONED will be used to indicate 
that none of avallable options for a parameter are desired. 


242e4e3 Parameter_Names and Descriptions 


The parameters are described in alphabetical order. 
Parameter 
Name Alias Parameter Description 


AUDIT AD This parameter is used to indicate that 
the product is being run for audit 
testing. The parameter causes the 
selection of any other parameters which 
may be needed for audit testing as well 
as selecting the method of processings 
which may differ from normal processing. 
Each product must provide a list of Items 
affected by the AUDIT parameters. For 
examples in COBOL the fist of items might 
include the mode where displays of 
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numeric items would not be edited. 


Single option parameter. Default: the 
option Is not selected. 


AUDIT = ON selects this option. 
BINARY _OBJECT % Rinary Object code output file. 
B = <file> 


This parameter specifies the fille to 
contain the object code or text produced 
by a compiler or assembler. 


B=$NULL indicates that no such binary 
object code output file is to be written. 


Single specifled value parameters default 
= $LOCAL.LGO 


COLLATING _SEQUENCE_X SEQX Collatina sequence (X = Name or Ns Step 
: or S» Remainder or R»s Alter or A). The 
parameters SEQN,» SEQS,s SEQR and SEQA 
control definitions of collating 
sequences for an applicable product. 


SEQN. The SEQN parameter signals the 
start of a collating sequence 
definition. The definition of one 
collating seauence continues with SEQSs 
SEQR,y SEGA parameters; it is terminated 
by any parameter not one SEQS» SEQR» 
SEQA. The form is: 


SEQN = <name>» where name is the name of 
the collating sequence. 

SEQS. Each SEQS parameter specifies 
either a single step or a range of 

steose. The form is: 


SEQS = €value-list>»s where the 
expressions in the value list are 
character expressionse 


SEQR. This parameter specifies al} 
characters in the character set not 
specified in a SEQS parameters explicitly 
or implicitiye The form is? 
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COLUMNS 


COMPILE 


COMPILATION 
DIRECTIVES 


CI7OLCOMPATIBLE 


COL 


cD 


cc 


SEQA,. This parameter may be specified to , 
alter ali equated characters In output 

records so they become the first 7 
character in the appropriate SEQs he 
parameter. The form is? 


SEQA = ONe iv 


This parameter specifies three values: 
starting and ending columns containing 
source and column containing a directive 
to the product (each product for which 
such a directive is. supported will define 
the meaning of the information In its 
directive column). For examples PL/I may 
define the directive column as containing 
a print carriage control character. 


Single specified value list; default * 
(lsn) where n is ianguage dependent. 


Compile fille. 


This parameter specifies the output file 
on which compiler source statements are 
writtene Examples are?: the output 
produced by a conversion aid utility; the 
updated source output by the source 
maintenance utility for input to an 
assembler or comojijer. 


Single specified value parameters 
default = COMPILE, 


If selecteds compilation directives (see 
SIS section 244) will be recognized. 
Otherwise compjlation directives will not 
be recognized--if directives are expressed 
as a special form of comment they will be 
treated as are all other comments. 


Single option parameter. Default = ON» 
directives are recognized. 


If selectedys all possible CYBER 175 to 
CYBER 186 product differences will be 
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converted to the CY180 version or 
diagnosed with messages. For exampies in 
COBOL items specified as COMP=4 wild be 
assumed to be COMP. Al! products will 
provide a list of such conversions or 
assumptions. 


Single option parameter. Default: the 
option is not selected. 


CI7O_COMPATIBLE = ON selects the option. 
Debugging option 


This parameter specifies the debug eptions 
to be selected, Ail products need not 
support all options. Multiple options may 
be specified. The defined options are: 


DS Debugging statements. Al? debugging 
statements will be compited. A 
debugging statement is a statement in 
the source which Is ignored by the 
product unless this option is 
seecified. Debugging statements 
usually specify debug actions for the 
moduie containing them. See also 
section 26427 of this standard. 


NC No checkings Do not generate 
parameter checking information as part 
of the object codee Unitess NC is 
specifiedsy aii compilers which support 
checking will generate actual informal 
parameter description Information in 
the object code to enable toad=—time 
detection of parameter mismatches. 


NT No tablese Do not generate line 
number and symbol tables as part of 
the object code. Uniess NT is 
specifieds line and symbol tables are 
generated on all compiles. 


NC Object code regardless. Produce 
object codes regardless of errors in 
the source and severity of such 
errorse For compilers, execution of a 
line containing a fatal error should 
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QEFAULT_UCOLLATION 


NIRECTIVES 


He 


NTR 


result In a call to an object time 
routine which will terminate the 
execution with a message. (See 
section 3.4 for error status returned.) 
Products with no object time library 
may generate a zero (program error) 
Instructon for lines in error. 


TR Flow tracing. Activate trail progmats 
in the source programe. Uniess TR is 
specifieds trace progmats have no 
effect. 


MultIele option parameter. The default Is 
NONE 


This parameter specifies the weight table 
to be used for the evaluation of character 
{string) retational expressions and to be 
used by intrinsic functions which are 
collated sequence dependent (for example 
CHAR and ICHAR in FORTRAN). The defined 
options are: 


Uoor USER 
A user specifjed weight table Is 
used. In FORTRAN a collection of user 
callable procedures is provided for 
manipulating the user weight table. 


F or FIXED 
A fixed (unmodifiable) processor 
specified weight table is used. 


Single specifled value parameters 
default = FIXED. 
Directive File. 


Additional parameters willl be read from 
this file after all of the control 
statement parameters have been reade 


DIR=file-name 
Parameters will be read from files 
file=-name. 


DIR=(file-namellsfile-name2] .« « 2) 
Parameters will be read from the 
files in the order that they are 
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ERROR 


ERROR LEVEL 


EL 


named, 


Multipctle specified value parameter » 
defauit = NO ADDITIONAL PARAMETERS ARE 
READ. 


Error File, 


This parameter specifies the name of the 
file to receive error tisting 
information. In the event of an error 
{of EL specified severity or higher) the 
diagnostic is written to the E file. It 
is hiahly recommended (though not 
required) that a product also output the 
offending source tine or tines to the E 
file in conjunction with the diagnostic. 
Tf there Is a fisting File (see L 
parameter) the error line and diagnostic 
are also written to the L file. If the 
file name of the E file is the same as 
the File name of the L files then the 
error fine and diagnostic are not written 
twice. 


Single specified value parameter» 
default = the listing file specified by 
SERQORS 


Error Level. 


This option indicates the severity level 
of diagnostics to be printed on the 
user's listing. The fevels are ordered 
by Increasing severity. Specification of 
aparticular tlevel selects that level and 
all more severe levels. Products wili be 
allowed some flexibility in specifying 
the kinds of diagnostics that fall In 
each of the six categories: 

non=standards machine dependents, trivial, 
warnings fatals and catastrophice The 
following descriptions are provided as a 
guide. ‘The product's status parameter 
will be set according to the value of 
termination error tevel (TEL).' The 
fevels In increasing order of severity 
are? 
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T Informationat. This is an 
informational message used to flag a 
suspicious usages. The syntax is 
correct but the usage jis 
questionable, For 170 compatibility, 
products are free to use 'T* in 
addition to 'I'. However, output 
will always be It, not 'T!, 


Wf Warninge This is a dlagnostic where 
the syntax is incorrect but the 
product has made an assumption (such 
as adding a comma) and continued. 
Messages indicating attempts at error 
recovery are at this level, 
Niagnostics of W level should be 
errors that the user can avoid by 
program modification. 

F Fatal. This is a diagnostic which 
prevents the product from processing 
the statement in which it occurs.e 
Unresolvable semantic errors aiso 
fall into this class. Such errors 
may not relate to a specific 
statement in the program unite 
Errors of type "TERROR? will be 
treated as equivalent to 'FATAL'S,. 


is Catastrophice This class of error is 
Fatai to continued processing. The 
product is unable to continue work on 
the current program unite Howevers 
it should still advance to the end of 
the current program unit and attempt 
to process a subsequent unit (if the 
product specificaton allows multiple 
program units in a compilation). 


Single specified value parameters 
default = We 


EL=NONE causes no errors to be fisted. 


ESTIMATEDLNUMBER_ ENR Estimated Number of Records. 

RECORDS This varameter specifies the estimated 
number of records to be processed by a 
product. For examples, SORT can use it to 
cause seiection of efficient modes of 
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EXCEPTION 


EXPRESSTON_ 


EVALUATION 


EXC 


processingse 


Single specified value parameters 
default = BOOCGO/MRL. 


This ts a file containing exception 
information. Products will be allowed 
Flexibility in defining its contents. 
For axampies SORT MERGE will use it for 
eut-of-order merge input records. 


Single specified value parameters, default 
is product dependent. 


The options of this parameter control the 
style of code generated for the 
evaluation of source expressionse Note 
that the processing controiied by this 
parameter is separate from that 
controlled by the optimization ltevei 
parameters, but may affect the extent to 
which optimization is possible. The 
defined options are: 


C or canonical 
The code generated to e@vaiuate an 
expression will mirror the expression 
interpretation rules as defined in 
the product specification. For 
FORTRAN this would be section 6 of 
the ANSI standard. This option also 
serves to inhibit the CCG "regroup" 
option, 


ME or maintain exceptions 
Inhibit code optimizations which 
eliminate instructions that might 
cause hardware exceptions at 
execution time. This option also 
serves to inhibit the CCG 
“unsafe _to_safe™ option. 


MP or maintain precision 
Inhibit code optimizations which 
change a floating point operation to 
a new form that is mathematically 
equivalent but not computationally 
equivalent, This option also serves 
to select the CCG “maintain, 
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precision™ option, 


R or reference 
Intrinsic functions (e.9. those 
defined jn CMML) for which a 
procedure call is generated will be 
cailed by reference rather than by 
value. 


Multiple option parameter. 
Default = NONEs none of the options is 
selected. 


EXTERNAL _TNPUT_ EX. External input file. 
FILE INPUT 


This file is for use by products which 
provide the capability of temporarily or 
alternately obtaining source statements 
from a file external to the input file. 
For examples the COBOL COPY statement. 


Single specified value parameter 3 
default = $NULL. 


FORCEDLSAVE FS If selected, the definition status, of 
all entities within a subprocedure of a 
program will be retained upon exit from 
that subprocedure. Effectively this 
disallows placing any variables on the 
stacke 


Single option parameter. Default = OFF» 
definition status need not be retained 
except where so required by the product 
specification. 

FROM Did file. 
This parameter specifies the data input 
file for the product. For example: the 
file from which a copy utility reads. 


Multiple specified value parameter 3 
default = OLO. 


INPUT i Input fille. 


This parameter specifies the source input 
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file name to the product, 
Single specified value parameter} 
default = SINPUT, 
H 
INTERACTIVE, Id» This parameter determines whether the product H 
DIALOGUE dialogs will Initiate an Interactive dialog with the users} 
dia Intead of operating in its usual batch-oriented H 
fashion. This dialog consists of questions and H 
explanations written by the product to file S0OUTPU?, 
and of user-supplied answers read from file SINPUT3 
The dialog can be invoked either from an iInteractifie 
terminals or a batch Job. H 
q 
3 
Single option boolean parameter ? 4 
3 
Ei 
YES This choice initiates the dialog. Ali othir 
Parameters on the command tine may H 
be ignored except STATUS. H 
NO Do not Invoke the dialog. ; 
omitted Same as NO. H 
KEY Key Fletd(s). 


This parameter specifies the key fields 
that determine the manner in which input 
data might be processed by a product. 
For examples, SORT will use the parameter 
to determine the order records will be 
sorted, 


KEY=<value~-iist> 
The value fist will contain one or 
more value sets. The resulting 
output will have been processed 
according to the key field described 
by the fteftmost value set. Input 
data with equal values for this key 
fieid will be processed according to 
the key field described by the next 
value set,» et cetera. 


Multiple specified value parameter. The 
default value set specifies 


keywl.s.mnr, where mnr is the 
smatiest of any MNR on a FILE 
control statement for input files. 
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LEADING BLANK_ZER0 LBZ If selected, leading blanks in numeric 
fields are treated as zeros in arithmetic 
statements and comparisons. If not 
selecteds numeric fields that contain 
blanks are in error.e 


Single option parameter. Default: the 
option is not selected, 


L8Z = ON selects the option. 
LIST L Listing file. 


This parameter specifies the file where 
the product writes the source listing» 
diagnosticss statisticss and any 
additional list Information (see LO 
parameter). 


Singje specifjed value parameters 
default s$LIST. 


LIST_OPTIONS LO Listing options.» 


The options of this parameter specify 
what extra information will appear on the 
listing file (LIST parameter). Multiple 
options may be specified. The defined 
options are: 


A Attributes. A isting of the 
attributes of each entity defined 
within the program is produced. If 
R was selecteds the references are 
shown on the same listings See 
section 3.3.5 for more information 
on attributes. 


B Prohibit Banner. The banner is not 
sent to the Listing file. 


RO Byte Offset. (Release 2 feature) 
Tf source statements are Jisted»s an 
offset field fs included (see 
section 343+323)4 This option is 
meaningful only for wide format 
listings. 


DE NETAILED EXCEPTIONS.» Print out 


eit 
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exception file messages as often as 
arecord is sent to the exception 
file, 


Map. A storage layout map for 
common blocks and equivalence groupse 


Merge Statistics. Turn on tisting 
of merge statistics, 


Nbject code listing. A listing of 
the generated object code with 
Instruction mnemonics. 


Prohibit prompt. The normal input 
prompts are not sent to the Listing 
file. 

Cross reference listinge <A cross 
reference of program entities 
showing locations of definition and 
use within the program. 


Cross reference Jisting of all 
program entities whether referenced 
or not. 


Record Statistics. List the 
statistics for the records 
sorted/mer ged. 


Source. Source listing of the 
programe 


Source fisting of ail source 
statements including lines turned 
off by a source embedded NOLIST 
directive. (See section 22442) 


Source original. Provides a tisting 
of the original sources. For 
examples in COBOL» this listing is 
produced before expansion of "COPY" 
and "REPLACE™ statements. 


Multiple option parameters, default = S,. 


LO = NONE causes none of the list options 
to be selected. 
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LITERAL CHARACTER Lc This parameter can be used to change the 


character that delimits non-numeric 
literals, Default titeral character is 
quotation mark, 


LO*OFF Js an errore 


MACHINE DEPENDENT MD This parameter specifies whether use of 
machine dependent source features is to 
be diagnosed and if so» how severely. The 
severity level is one of the following: 


YT or informational 
Woor warning 
F or fatal 


Errors of type 'ERROR! will be treated as 
equivalent to 'FATAL'. 


Single specifled value parameter, 
Default = NONE» machine dependencies are 
not to be diagnosed. 


MASS USTORAGE_LIMIT MSLIMy Mass Storage Limit. This parameter 
MSL specifies the maximum number of 
characters that may reside on mass 
storage during execution of the product 
(for example, SORT). 


MSLIM = expre The number of characters 
indicated by expr is the mass storage 
limit. Expr must be an integer. 


ONE_TRIP_DO NTD This parameter selects the minimum trip 
count for FORTRAN DO-loops to be one 
rather than zero. 


OPTIMIZATION NPT Optimization. 


This parameter specifies the level cf 

ob ject code optimization. Ali products 
nead not support ail defined levels. 
However if product supports a defined 
level» It must be selected by the 
specified option namee Ideally all 
products should recognize all defined 
options and issue informative dlagnostics 
for unsupported options that the user 
selects, <Alicowabile options are: 
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OWNCODE_LFILE 


OWNCODE FIXED 
LENGTH 


OWNCODE MAXIMUM 
RECORO_LULENGTH 


OWNF 


OWNFL » 
OFL 


DWNMRL 
DMRL 


DEBUG Object code is stytlzed to 
facilitate debugging. Stylized 
code contains a separate packet 
of Instructions for each 
executable source statements 
carries no variable vatues 
across statement boundaries in 
registers» notifies DEBUG each 
time a beginning of statement or 
procedure is reacheds etce 


LOW Lowest level of production 
quality code. Code is not 
completely stylized. 


HIGH High tevel of production quality 
COde. 


Single specified value parameter; 
default = DEBUG 


Qwneode file. For products which provide 
the capability to specify user generated 
owncode procedures. This parameter 
specifies the source of owncode 
procedures, See parameter OWNne 


OWNF = file-name. File file-name will be 
loaded. 


Nefault = omitted. 


Qwneode Fixed Length. See also OWNn. 
This parameter specifles the record 
length in characters of all records that 
will be input to a product from any 
owmncode procedure. See also OWNMRL 
Darameter. 


QOWNFL = <integer>. Every record supplied 
by an owncode procedure will contain 
exactly <Integer> characters. Default: 
(See OWNMRL). 


Dwncode_Maximum_Record_Length. The 
maximum fength In characters of any 
record supplied by any owncode procedure 
Is specified by this parameter. This 
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QOWNC ODE _ PROCEDURE_n 


RETAIN, 


QRDER 


ORGINAL 


OWNA 


parameter may not be specified if the 
product has input or output files and if 
any of their associated MRL's are at 
feast as large as this MRL. See also 
DWANne 


OWNMPL = <integerd,. There will be at 
most <Iinteger> characters in any records 
supoltied by an owncode procedure. 


Default: If OWNFL and OWNMRL are both 
omitteds the record fength specification 
will depend on the length specifications 
of the Input and output files. If alf 
input and output files have fixed-length 
records of the same length that length 
wiil serve as the default for OWNFL. 
Otherwise the largest MRL or FL from any 
input or output file will serve as the 
default for OWNMRL. 


OQwneode procedure n (n = ls 29 39 49 5,» 
eeve)e The maximum of n is eft to the 
Individual products Owncode procedures 
ara user written routines that may be 
loaded with the product and executed at 
soecified points during product 
execution. See other OWNCODE 
parameters for more information on this 
capability. 


The procedure specified by this 
parameter will be executed at a 
specified point n during product 
execution. 


OWNn = proc uname. The procedure 
proc uname will be executed at a 
specified point ne 


Default: No procedure wlll be executed, 


RETAINs Ratain Orginal Order. 


RET 


Equivalent records or records with 
equivalent identifying characteristics 
wiil be output in the same order as 
input by a producte For examples with 
SORTs the equivalent identifying 
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RUNTIME CHECKS 


SEQUENCED_LINES 


RC 


SL 


characteristics would be equal keys. 
The order in which multiple input files 
are specified is the order in which 
records with equivalent characteristics 
are retained with this parameter, 


RETAIN * ON. Records with equivalent 
characteristics will retain their 
orlginal order. 

RETAIN = OFF. Records with equivalent 
characteristics will not necessarily 
retain their original order. 

Default: Same as RETAIN=0FF. 

This parameter controls which runtime 
checks are compiled into the object 
code and/or selected for runtime 
library routines. Runtime checks are 
product dependent but if a product 
supports one of the ones described 
heres it must be selected by the value 
soecified, Defined values are: 


R Range checks. This option selects 
range checking for one or more of 
the following 
—- character substring expressions 
- scalar subrange assignments 
~ case variables 


$ Subscript checks. This option 
causes subscript and index 
references to be checked to ensure 
that they are within program 
defined limits. 


T Tag field checks. Selecting this 
option ensures that accesses to 
variant records are consistant 
with the value of their tag field 
(if one exists). 


This is a multipie value parameter. 
Default is ali supported values 
selected. 


This parameter selects FORTRAN 
sequenced mode source line format as 
described in section 3.2 of the FIN180 
ERS. Note that this format is 
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SMURCE 


STATEMENT_LENGTH 


STANDARDS DIAGNOSTICS 


St 


$D 


incompatible with the standard SIS 
(section 2.2.2) source tine format 
which allows the length and location of 
a fine number to be specified in the 
source file attributes. 


Single option parameter. Default = OFF, 
source tines conform to the standard 
STS formate 

SCU input. 


Line images of the generated program 
will be written to this files in a 
format acceptable as Input to SCU. 

Each program unit on the SS file will be 
preceded by an SCU directive which 
indicates the beginning of a new source 
dack,. 


Single specified parameter values 
dafault = NULL. 


Statement lenath. This parameter 
specifies the maximum length of a 
source statement. The default is to be 
specified by each product which 
recognizes this parameter. 


Standards diagnostics. (ANSI or other 
applicable standard). 


This parameter specifies whether use of 
non-standard input source statements 
are to be diagnosed and if so» how 
severely. There are two values 
defined: severitys and name of 
standard. The severity is one of the 
following: 


1 Informational error. Standards 
errors are treated as errors with 
this severity. 


W Standards errors result In warning 
messagese 


Fatal errore Non-standard usages 
result in a fatal error. 


“Ti 
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STATUS 


SUM 


ST 


Errors of type TERROR! will be 

treated as equivalent to 'FATAL!,. 
The second valuey name cof standards is 
to he defined by the products as 
appropriate. If this parameter Is not 
specified, then non=standard extensions 
to the product are allowed, (not 
diagnosed as errors). 


STO#NONE causes standards errors not to 
be diagnosed. . 


Multiple specified value parameters 
default = NONE. 


Status Variable. 


This parameter specifies the name of 
the SCL status varjable to be set by 
the product to indicate the occurrence 
of error conditions. See sections 3.4 
and 4.4 for an account of the status 
variabie. See also NOS/VE ERS. 


Singie specified value parameter. 


Errors of type 'ERROR' will be treated 
as equivaient to tFATAL®. 


Default status variable name Is 

STATUS. See Error Processing 

section 34% for a description of error 
processing that resuits from use of the 
default status variable. 


Sum Fleld(s). 


This parameter specifies that units of 
input data having key fields equal (see 
KEY parameter) may be combined Into 
items or units in a product dependent 
manner e 


(For examptes SORT will use the 
parameter to combine all records, 
having key fieids equals into a single 
record. Each sum field in the new 
record is formed by summing the values 
in the corresponding fields of all 
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SUBPROGRAM 


TAPE_SCRATCH_FILES 


TERMINATION_LERROR_ 
LEVEL 


s$P 


TAPES» 


TEL 


equal records.) 


SUMe¢value-jJist> 

The value list will contain one or 
more value sets. Units of input 
data with equal key values wild be 
combined into new units or items 
and fields specified by the value 
sets will be summed», according to 
product specifications and needse 


Multipie specified value parameters 
default = NQ SUM FIELDS. 


If this option is selected, the program 
is compiled as a subprogram instead of 
as a main program. 


Default: the ootion ts not selected. 


SUBPROGRAM = ON selects the option. 
Tape Scratch Files. 

The tapes with the names specified by 
this parameter will be used by the 
product to reduce the disk space used. 
Thea tapes must have already been 
requested prior to executione The form 
is? 


TAPES = (file name »sflle_name 2+.) 


Defaults: Tape scratch files will not 
be usede 


This parameter specifies the minimum 
diagnostic severity ftevel which will 
cause a product to return an abnormal 
STATUS upon completion of processing. 
A normal status Is returned otherwise, 
Tha severity level is one of the 
following: 


or informational 
or warning 

or fatal 

or catastrophic 


For 170 compatibititys products are 
free to use 'T? in addition to 'I',. 
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However, output wlll always use "It, 
not "Tt, Errors of type PERROR! will 
be treated as equivalent to 'FATAL'. 


Single specified value parameters 
default = Fe 


TEXT UNAME TN Names of texts to be read From the 
files or libraries specified by the 
TEXTLRESIDENCE parameter. The total 
number of values allowed is product 
dependent. Products that have a text 
name directive may choose to support 
the TEXTLRESIDENCE but not the 
TEXT_NAME parameter. A fatal error 
occurs if any of the texts specified is 
not Found. 


Aultiple specified value parameter» 
dafau!lt Is no text. 
TO New file. 


This parameter specifies the data 
output file for the product. For 
example: file to which a copy utility 
writes. 


Single specified vatue parameter 35 
default = NEW. 


TEXTLRESTIDENCE TR Hames of residences (f.e. files or 
libraries) to be searched to find texts 
specified by the TEXTLNAME parameter or 
by product directives, The total 
number of values allowed is product 
dependent. If no text names are 
provided the first text of the first 
TEXTLRESIDENCE name Js the only one 
used. If text names are provided and 
TEXTLRESIDENCE is omitteds the default 
for TEXT RESIDENCE will be the 
TEXT_LNAME parameter fist. In case 
texts of duplicate names exists, the 
first one found (in the order in which 
TEXTLRESIDENCE names are listed) Is 
used. For each name in the 
TEXTLRESIDENCE parameter tists the 
product will took for a local file with 
that name; If not founds the global 


. 2-26 
CYBER 180 System Interface Standard 

84/67/27 
229 INPUT 

2elete 3 Parameter Names and Beascriptions 


a ita i CON ae) eR este ate DARI MEY DR: KE mito Gee EE Hone ORE AOE oR AOR NN foe ane UAT ARR GA OM me one ae OR i TY I ee A ORE eee AE eu NO eee MER TR ae ORR Ge ae) Ae AE Ae Le en atin A OE EE tin A OD Wie ae ee 


library set will be searched for a 
library with that name. If the name fs 
not founds, as a file or fibrarys a 
fatal error will occure 


Multiple specified value parameter. 
Default value tist is text name vatue 
list. 


example 1:3 If file Fl contains texts As Cs and D 
and ilbrary L2 contains texts 8B and C 
and file F3 contains texts E and A then 

TN=(Av8B8aCeDeoE) and TR=(Flstl2sF3) 
wit! result In selecting texts as 
follows? 

A» Cy and 0 from flie Fi 
BRB from library L2 
E from file F3 


example 23 In the above examples if in addition to 
a library L2s the user has 3 local file 
named L2 containing texts B and E» then 
TN=(AyaPBaCoD,sE) and TR=(Filytl2,F3) 

will resuit in selecting texts as 
follows 

As Cys and D from fille Fil 

BR and — from file L2 

nothing from library L2 

nothing from file F3 


TERMINAL _TYPE TT Tarminal Type. 


TT=COR 
Correspondence Selectric APL 
terminal. 


TT=APL 
This type is appropriate when the 
communications system transjates 
APL terminal codes into a standard 
intermediate code. 


TT#ASCII 
For full ASCII terminats not 
equipped to print the APL 
character set. <Aiso used for 
non—APL correspondence terminals. 


TT=UCA 
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For full ASCII terminats. This 
avoids frequent use of the shift 
key for ftetters. 


TT=BATCH 
For devices that support the ASCII 
64—character set. Usually used 
for batch or remote batch ASCII 
printers. 


Single specified value parameters. 


Nefault Is APL for a time-sharing job} 
and BATCH for a batch or remote batch 
VERTFY_MERGE_ VERTFY,s Verify merge input order. Selection of 
INPUTLORDER VER this option causes verification that 
input records to be merged are in 
correct order. The form is? 


VERTFY = ON. Verify for correct order. 
VERTFY = OFF. Oo not verify for 
correct orders 


Default: VERIFY #* OFF. 
WORKSPACE WS Initial Workspace specification. 


This parameter specifies the workspace 
to be activated when the product Is 
called, The parameter is specified 
with values consisting of the following 
parameters defined in the NOS/VE ERS: 


file 


2e3 JQURCE INPUT 


This section deals with the standard for the orocessing of 
source input files by product set members. In this 
contexts, a file can refer to data originating from an 
interactive terminal as well as conventional storage 
devices. This standard addresses the areas of source file 
organizations, statement formats, blank compressions and 
response to an empty Input file situation. 
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20301 SQURCE INPUT FILE ORGANIZATION 


Source input to CYBER 180 product set members may be 
designated by the I directive on the control statement, 
If the I diractive is omitted» the source input defaults 
to the standard input file (batch mode) or terminal 
(interactive mode). The source Input has a sequential 
structures, and is accessed by means of standard Record 
Manager interfaces. 


Pasitioning of the source Input at open time Is 
constrained by the requirement to allow different product 
set members within the same job (eege different compilers) 
to access the same File for their input. Therefores the 
source input is opened with no-rewind unless the rewind 
parameter Is specified on the control statement (see 
Keywords and Parameter Descriptions in section 2.2). 


22322 SOURCE STATEMENT FORMAT 
Each record in the source input contains one to three 
parcels of data: 
* statement Identifler (optional); 
e line number’ Coptional); 
° statement body. 


Products should be able to handle the optional statement 
identifier and !ine number. 


The source input statement may take the following forms,» 
where 


b represents the statement bodys 
1 represents the line numbers 
s represents the statement identifiers 


and brackets specify the optional portions of the form: 
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2e3e2-1 Statement Identiflerc 


Input source records may contain optional statement 
identifiers such as SCU identifiers. If presents they 
occupy either the first or last !n'* characterss where 'n! 
has a maximum value of 18. If the statement identifier 
occuples the last character positions of a records all 
records must be the same fength. The location and length 
of the identifier are file attributes; they are made 
available via an operating system request. 


This feature is to allow files created by source code 
utilities to be used as source input. 


223.2.2 Line Numbers 


Line numbers are numeric entities used by compilers and 
editors. In generals editors will affix line numbers to 
lines and compilers will use these Sine numbers for 
diagnostics» cross reference mapss run time error 
messages» etc. Line numbers should not be confused with 
statement identiflers that are produced by SCU and are 
alphanumeric, 


The location of the line number in a text line may be 
immediately to the left or the right of the text of the 
line. The position of the tine number field is conveyed 
via the file attributes. The fine number field may be 

from one to six characters in sizes The only valid 
characters Ih the field are blanks and the decimal digits 

9 to 9. Leading blanks are ignored. A iine number is 
terminated by end of field or one or more biank characters. 


Additional semantics for the line number field will vary 
from processor to processor. In particulars many 
compilers may not accept more than six digits. Another 
example Is the cross reference map produced by CCM which 
only has space for a six digit tine number. Most 
processors will’ also Insist that the tine numbers be 
uniques ascendings and that every line be numbered. 
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The body of each source Input record is that part which 
represents the data to be scanned or processed by a 
product set member. It begins In position 1 if there are 
no statement Identifiers, or if the identifiers appear at 
the end of the record. Otherwises it begins in position 
(n+1) where 'n' is the ftergth of the statement identifier. 


The maximum size of the statement body is product set 
member dependent and conforms to the size specified for 
the associated language. Source records shorter than the 
maximum are scanned to the end of the record. Records 
exceeding the naximum size are truncated (i.@. data is 
transferred up to the maximum); a diagnostic is returned 
by the Record Manager. 


2e3e2e% Blank Compression 


The CYBER 139 Record Manager is responsible for 
compression/expansion of blanks. The capabllity to read 
the source Input in compressed form is not provided. If 
the requirement for this capability emerges (for 
performance optimization)» it will be addressed in a 
revision to the standard, 


2e3e2e5 Enpty_Input_Eile 


Diagnosis of an empty Input file results In the Issuance 
of a standard fog message: EMPTY SOURCE INPUT FILE 
(formatted In accordance with conventions stated in 
section 3.2). If the job involwed is interactive in 
origins the message Is also sent toe the terminal (see 
section 3e2e1e22)2 In additions generation of the primary 
output of the oroduct set member involved (e.9. file 
specified by 8 parameter for compilers) is suppressed and 
the SCL STATUS variable (refer to section 2e2e6422)5 is set 
to reflect the error. 


223-226 Null Source Line Convention 


The number of records in the source file should be the 
same as the number of source Jines In the source IIste 
Even though a null record has no datas, the record should 
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not be Ignored. Sinces In the source JIist» the absence of 
all characters in a record looks the same as a record 
containing all blanks» null records should be mapped to 
all blanks. 


20303 DISPOSITION OF INPUT FILE 


The Final action to be taken with respect to the source 
input file ts dependent on the manner of termination of 
the product set member. For normal termination, the input 
file is closed with the no-rewind option; this includes 
the case where an empty file Is detected. For abnormal 
terminations the product set member is responsibie for 
positioning the Input file as if normal processing had 
occurreds using appropriate facilities of the Record 
Manager. 


24 COMPILATION DIRECTIVES 


The user of a Compiler may control various activities of 
the compiler by specifying one or more compile time 
directives. The directives are expressed either in a 
special form of a comment within a particular language 
(ee.g.e FORTRAN»s COROL) or in special source statements if 
the language provides such statements (eeg2 CYBIL). 
Compiters that already have special source statements for 
directives do not have to process directives embedded 
Inside comments. Compilers which now have compilation 
directives in comments should honor both old and new 
directives. When a compilation directive conflicts with a 
control statement parameter options the compilation 
directive overrides For exampies the options for the 
parameter LO will be overridden by a conflicting directive 
unless specifically stated otherwises such as LO#SA. 
However control! statement parameters denoting file status 
or destination would take precendence over directives. 

For example LIST=tnul!l would take precedence over any 
directives requesting that something be tisted. 


“Since the major programming languages are subject to 
standardization by bodies such as ANSI» FIPSs and ISO» 
initial comeltance with the form of compilation directives 
in this section may have to be altered in the event of 
standards covering this areae Because of the long term 
possiblity that the major languages will be differents 
full uniformity across 186 products ts untikely. 
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Therefores oroducts with CYBER 170 directives that do not 
conform to the syntax contained here should retain 
compatibility with the CYBER 170 form to minimize 
migration problems rather than cause a conversion in going 
to 180 and possibly have to cause a second conversion to 
comply with external standards. New directives in areas 
which will never be subject to standardization should 
follow the forn of this section. 


The Compilers support two general classes of directives: 
e Compiler Cal! directives 


* Source Embedded directives 

As discussed In section 2.2» the directives specified on 
the command calling the compiler are established for the 
entire compilation process. They apply to all subsequent 
compilation units (program modules or subroutines) within 
the compile process. 


Source embedded directives are established only for the 
compilation unit In which they appear. They are expressed 
either in a special form of a comment within a particular 
fanguage (2@.9. FORTRANs COBOL) or in special source 
statements if the language provides such statements (erg. 
CYBIL). Compoliers that already have special source 
statements for directives do not have to process 
directives @mbedded inside comments. The syntax of a 
compller directive within a comment is as follows? 


% directive € »sdirective J] »« » » 


Exampie — FORTRAN source embedded directives 
C% directive - C in column 1 


Example — CO80L source embedded directives 
*% directive - * in column 7 


Multiple directives may be contained on the same Input 
statements 


where djrectives have parameterss they follow SCL rules. 


Source embedded directive format errors are diagnosed with 
warning or fatal class error messagess as appropriate. 


The following standard applies to compilers that process 
directives embedded Inside comments. A compller ts not 
required to Implement al! the features listed belows nor 
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2e4e1 PAGE EJECT 


EJECT 


This directive causes the page line counter to be reset 

to le When the line counter is reset to l» a standard 
listing header willl be written on the source listing prior 
to the next source line. This directive will be listed 
before the page line counter is reset to 1. If the page 
is at top-of-form when this directive is processeds it is 
processed as a “"no-oo”", If a continuous page is being 
written, this directive will simply resuit in a triple 
space without a new listing header. 


20402 SOURCE LISTING 


LIST and NOLIST 


The NOLIST directive causes the listing of the source 
modules incuding comolter directivess to be suppressed at 
this point. The LIST directive causes the listing of the 
source module to resume at this point. The directives 
LIST or NOLIST are tisted at the point they occur. 


20403 LINE SKIP 


SPACE = number 


This directive causes the specifled number of print tines 
to be skipped at the point in the source module listing 
that it is orocessed. This directive wild be tisted 
before the skin action starts. If the page Jine counter 
is exhausted before the specified number of ifnes have 
been skippeds the line counter is reset to 1 and skipping 
terminates. 


number 3 integer vaiue 1 thru n3 if omitted 
{including the “="),y the defauit Is 1. 
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204361 LINE_SPACING 


SPACING = number 


This directive specifies the number of lines to be 
advanced before each source tine is listed. The new value 
for spacing wll! take effect with the next line following 
the spacing directive. When listing a source line if the 
page line counter is exhausted before the specified number 
of lines have been skippeds the fine counter [s reset to 1 
and skipping terminatese 


number: integer value 1 thru 3 indicating singles 
double or tripie spacing; if omitted 
{including the "x"), the default is ae oa 


20404 TITLE LINES 


TITLE = character string 

SUBTITLE = character string 

These directives define strings of alphanumeric characters 
in SCL format which willl be printed following the standard 
page headers on the source module listing (see TITLE Lines 
in section 3). TITLE causes 3 page eject to occurs unless 
the page is already at top-of-form. TITLE is listed at 
the top of the new page. 


SUBTITLE also causes a page eject to occurs, unfess the 
page is already at top-of-form or TITLE has just been 
processed. SUBTITLE Is listed at the at the top of the 
page following TITLE if there is onee 


Compilation Directives 
20425 RANGE CHECK 


RANGE and NORANGE 


The RANGE directive directs the compiler to generate 
additional object code which performs range checking for 
subscriptss indexessy scalar assignments, case variabies» 
etce 


The NORANGE directive directs the complier to not generate 
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additional range checking object code, 


The default for the compilation unit is NORANGE. 
2e%e6 EXECUTION TRACE 


TRACE and NOTRACE 


The TRACE directive directs the compiler to generate 
additional object code which facilitates tracing the flow 
of the program during execution. The TRACE directive is 
lonored unless the DEBUGSTR parameter is given in the 
product call command. 


The NOTRACE directive directs the compiler to not generate 
edditional flow tracing object code. 


Minimum trace information wiil always be provided. Sea 
section Zetele2s 


The default for the compliation unit is NOTRACE. 
2a4%e7 DERUG STATEMENTS 


DEBUG and NODE3USG 

Source Input statements that are to be compiled only for 
debugging purposes are enclosed between DEBUG and NODEBUG 
directives. Enclosed source statements are compited only 
if the DE8UG*DS Is given in the product call command. 


20%e8 SEQUENCE CHECK 


SEQUENCE and NOSEQUENCE 


The SEQUENCE directive directs the compiler to check the 
Input source statement seauence numbers for ascending 
order. 


If a sequence error occurss it will be flagged with a 
warning diagnostic. (See section 2022422) 


The NOSEQUENCE directive directs the compiter to Ignore 
input source statement sequence numbers. 
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The default for the compilation unit is NOSEQUENCE. 


The SEQUENCE and NOSEQUENCE tines themselves are not 
checked for sequence, 


204.9 OAJECT CODE LISTING 


OB8JLIST and NOOBJLIST 


The OBJLIST directive directs the compiler to print the 
object code listing at this point. The NOOBJLIST directs 
the compiler to stop printing the object listing at this 
pointe. The object code will appear in the object code 
part of the listing (see section 3.344). 


OBJLIST and NOOBJLIST act Independently of LIST and 
NOLIST. The default for the compilation unit is NOOBJLIST. 


204.16 STACKING COMPILATION DIRECTIVES 


PUSH (compilation directive) and POP 

The PUSH command will polace the specified compilation 
directive on the top of the "directive stack". The POP 
directive wlll remove the top directive from that stack. 
This procedure wlll allow temporary alteration of the 
focal environment without permanently affecting the global 
environment. For exemoles if it is desired that a called 
common deck tists its name on the print files, regardiess 
of whether the entire common deck is being fisteds then 
the following would be placed In the common deck: 


PUSH (LIST) 
comment including common deck namee 
POP 


2.5 PROOUCT DIRECTIVES 


The format of product directives (commands) must follow 
the set of ltanguage rules and conventions of the System 
Command Languagee These directives frequentiy occur In 
products (often various types of utilities) that are not 
compilers and are thus listed separately. The standard 
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parameter names as described in sections 2222422 and 20501 
must be used as applicable. 


20501 STANDARD PARAMETERS 


These parameters occur frequentiy enough to warrant making 
sure that all commands using them do so In the same way. 


Parameter 
Name Alias Parameter Description 


BRIEF BR This parameter specifies that a brief form of 
information is requested for display at a 
terminal or print file. It is a boolean used 
in conjunction with the full parameter. The 
brief selection Is used as the default. 


FULL FU This parameter specifies that a full form of 
Information is requested for display at a 
terminal or print file. It Is a boolean used 
in conjunction with the brief parameter. 


COUNT cou This parameter specifies a count of units (e.g 
files records) associated with the command 
Function. The default value is one. 

FILE F This parameter specifies the local file name of 
a file used as the object of a command 
Functton. It is used when the file Is not one 
of the specific files identified in section 
Pece4e? {2eGe COMPILE, INPUT). 


WATT WAI This parameter specifies the requestor should 
be placed In a wait state if a request can't be 
immediately processed (e.g. a file is busy). 

It is a bDoolean used in conjunction with the 
nowalt parameter. 


NOWAITT NOW This parameter specifies the requestor should 
not be placed in a wait state if a request 
cannot be Immediately processed. It Is a 
boolean used in conjunction with the wait 
parameter. The nowait selection is used as the 
default. 


USER US This parameter specifles a user 
Identification. It is always the 3li=—character 
user and family names as specified to gain 
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PASSWORD 


UPON 


LIBRARY 


PA 


LI 


access to the system. 


This parameter specifies a 3l-character 
password needed to gain access to an entity or 
to execute a function, 


This parameter specifies the focal file name of 
an output file. It is used when the flle is 
not one of the specific files identified in 
section 2e2e4%ez CA ede LIST,» SINARY-OB JECT). 


This parameter specifies the local file name of 
a library flle (eeg- source Jibrarys, object 
library). 


22542 STANDARD COMMANDS 


Command 


QUIT 


These commands are requireads as a minimums if the functions 
described by the commands are included in the utility. 
Utilities may ootionalty include aliases to the required 
command, 


Description 


This directive enables the user to exits or get 
out of, a utility. 
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3.0 QUIPUT 


All products will follow a uniform set of conventions for 
generated outputs as specified herein.» Ali CYBER 186 
procucts will use the facilities of the CYBER 180 Record 
Manager for such outpute 


Sol RECOMMENDED NUMBES BASES 


The use of hexadecimal numbers on output produced by CY186 
software must be controlled to promote readability. Atl 
products will fallow the set cf guidelines set herein. 


Zelel SITUATIONS AND RECOMMENDED NUMBER BASES 


Address» Address Offset: Hexidecimal. When a length is 
specified in conjunction with an 
address or address offsets the 
length is represented in 
hexidecimal. 


Dayfile information: Decimal statistics, decimai 
resource timits. 


Dobject Code Listings: 
Instructions: Hexadecimal (4 or 8 hex digits) 
Operand fields: Decimal 


Branch Destination: Hexidecimal. The value Is the 
instruction offset of the 
destination instruction rather 
than the relative offset from 
the branch Instruction. 


Instruction ffset? Hexidecimale 


Core and File Dump: Various formats should be 
availables including 
hexadecimals, ascii» integer» 
floating point. 
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Page numbers? Decimal. 


The logs treated in this section are those maintained by 
the operating system. The OS provides interfaces to put 
items into the logs and the SIS provides conventions on 
how to use these Interfaces and on the contents of data 
put into the logs, 


The set of logs Is divided into two major classes» ASCII 
and binary» The ASCII logs contain only ASCII-encoded 
data. The binary logs may contain any type of data. 


The logs include: 


~ system log (ASC TT) 

~- job log (ASCII) 

- account log (binary) 

~ engineering log (binary) 

~- statistic tog (binary) 

- job statistic log (binary) 


3e2e1 ASCII LOGS 


Each ASCII tog contains a set of records ordered by time 
of antry into the log. Each record contains several 
fieldss some automatically provided by the logging 
mechanisms and some provided by the caller of the 
mechanism. Tha following fields are provided ty the 
logging mechanism: 


- time of day of the entry of the record Into the tog 


- origin of the message (commands program-issueds 
command from procedures etce -—— that is: cailers in 
OS rings may specify the message origin In the cally» 
callers In users rings may not and their messages 
are always "program=-Issued™), 


The system tog has an additional system-provided field to 
identify the message Issuing job. Also», each log record 
contains a field for data provided by the program making 
the record entry. 
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Except for certain operating system programss the 
interface to be used by the OS and product set for putting 
messages Into ASCII loas is that provided by the "message 
generator’, a facility of the OS (see NOS/VE ERS). The 
message generator is given a status record that describes 
the type of message and any variable data to be "edited" 
Into the message. The message generators 


- finds the appropriate message skeleton in a library 
which is in the current job library tist 


~ edits the variable data into the message 


- fogs the final message in whichever logis) are 
specified by a combinatlon of: 


* dastination specified within the message 
skeleton record 


* job option selection (e@sgee “log only errors”, 
"log all fatais™s etce) -- things such as 
message importance fevel are defined in the 
message generator call. 


-~ displays the message at a terminal depending upon 
job oaptian 


Tre use of a message generator eases? 

- consistency of messages within and across products 

- physical compression of message text 

- extraction of message types for documentation 

- routing/suppression of messages based upon message 
levels {e@.ae, trivial, fatal,» etc.) and upon user 
desire for only certain tevels ("levelt™ or 
“jmportance™ is specified in the message generator 
cally not In the message skeleton) 


- installation controi over what kind of messages 
should appear In the system log 


Arbitrary user-Initiated logging need not use the message 
generatore 
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3e2elel System Log 


In addition to the basic system—provided fleldssy each 
system log entry contains a field identifying the 
particular job from which the message came or to which it 
applies, 


Zetelelel PURPOSE 
The primary purpose of the system log is to serve as a 
repository for information regarding external system 
workload, That Is» the work the system was asked to do 
via commands and the high level responses of the system in 
regard to the commands. 

3ePelet»2 CONVENTIONS 
The system fog contains predominantly a subset of job tog 
messages that are of interest to the installation. This 
normally includes at least: 

- all system level commands (supplied by 0S) 

- all command completion messages 

- start of each joh execution (supplied by OS) 

~ end of each job execution (supplied by OS) 

- rerun of each job execution (supplied by GS) 

- systen Identification (supplied by QS) 

- other information supplied by the OS Jike dates 
hardware and software configurations and changes» 
deadstarts»s recoverlesys etc. 

The system tog should contain only indications of the 
major changes in state of the system and of individual 
jobs. 

The specific messages that should tbe routed to the system 
jog in the default "aseshipped™ system will be determined 
on a case-by-case basis using these general conventions as 


guidelines. 


Note that since massage destination (which log(s)) 
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instructions are separate from the message-issuing codes 
this determination does not involve code modifications 


Sea Job Logs Conventions for further guidelines. 


Ze2ele2 Job Log 


Ze2ele2oi PURPDSE 


The purpose of the Job Jog Is to hold a trace of Job 
execution. Information concerning the work requested and 
accomplished is recorded here. It provides a summary of 
the flow of the jobs problems encountered and charges 
accrued by the Job. 


Ze2ele2e2 CONVENTIONS 


Keep fog messages simple and short. Use the logs for 
summary Information. Use list files or binary logs for 
detailed or revetitive data. 


Messages longer than the Jistable output "narron™ format 
are discouraged. 


Simple completion massagas that convey no more information 
than "it's done” are not to be put into logs. In a batch 
cases completion Its obvious from the appearance of the 
next command. In an Interactive cases the OS will see to 
it that the terminal user is notified of completion. 


Completion nessages that convey a small amount of useful 
or interesting Information are encouraged in order to 
enhance the "live" appearance of the system. For examples 
"23 records sorted.” or “Cycle 25 used.". Information not 
speciflec to the operation performed should not be 
included, however (like CPU time for a compilation). 


Messages (at least the non=-brief mode ones) should have 
the general apoearance of normal sentences. That Iss they 
Start with a capital letter, are comprised of both upper 
and flower case letters» and end with a periods. When an 
“extended message” of more than one line must be Issued» 
each tine should nots howevers end with a periods but each 
sentence should. This familiar sentence-type structure 
adds to the "comfortable" feeling that we'd like our users 
to have for our system. 
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Accounting and low-level statistical and hardware error 
informatlon Is not to be elaced Into ASCII togs except by 
the QS. 

Message~at-a-time "current status” messages (like 
"compiling alphasee.e compiling betas..") are not to be 
placed in jogs. The TS will provide a means for programs 
to post these kinds of messagese The current message will 
be displayed at an Interactive terminal when requested by 
the terminal userse Posting of these messages is 
encouraged. 


The message generator will supply product and message type 
identification based upon the status record passed to {t 
in @ call. Products should not include this information 
in messagese 


When more than one datum is to be loggeds try to minimize 
the number of nessages Ifnes produced by putting more than 
one datum ona line. For examples issue: 


23 records sorted; Merge order 12 used; 14 insertions» 


rather than: 
23 records sorted. 
Merge? order 12 usad. 
14 Insertions. 


32202 3INARY LOGS 


Binary logs are provided in order to allow the recording 
of iog Information in a compact form that is readable 
primarily by programs. Each binary tog contains CYBIL 
records ordered by time of entry into the log. Each 
record contains several fields» some automatically 
provided by the logging mechanisms, and some provided by 
the caller of the mechanism. The following fields are 
provided by the logging mechanism: 


- time of day of the entry ef the record Into the fog 

~ the Identification of the job from which the record 
came or to which it applies (this field is not 
recorded In the Job statistic log) 


~ the origin of the record (system or non-system -=- 
indicates only whether the caller is inside or 


3~7 
CYBER 180 System Interface Standard 
84/07/27 
320 OUTPUT 
302-2 BINARY LOGS 


outside system ringss not which product or which 
system agency -—this latter information is given by 
the "indicator of the type of record” field.) 


Flelds provided by the caller include; 


- Indicator of the type of record (e@ege»5 number of FTN 
source statementss SRJs at end of jobs etc. --the 
Indicator codes willi be assigned and managed in a 
manner similar to that used for status condition. 
codes as described jin section 3.4) 


- variable data depending upon the record type 


Except for certain operating system programsy the 
interface to be used by the OS and product set for putting 
records Into binary !togs is that provided by the 
"statistics facility” of the OS. The statistics facility 
is given a data record that describes the type of record 
and any variable information associated with the record, 
The statistics facillty finds information about the given 
record type in a "table". This "table™ directs the 
statistics facility to do some combination of the 
following things: 


- add the variable item(s) to counter(s) 


- log accumulated counter values to a specified binary 
jog or set of binary logs when a thresho!d counter 
value Is reached or when a certain time has elapsed 
since the tast ™put™ to the logis) of the 
appropriate counter(s). The set of logs is 
specified in the “table”. 


- simpiy log this record In the “table-speci fied" 
log (s) 


The use of the statistics facility for binary logging 
easess 


- Installation talloring of what Is considered to be 
accountings performances etc. data. For example» 
site A may consider CPY time to be accounting datas 
while site 8 considers it e workload statistic and 
considers "number of statements compiled” to be 
accounting data 


- optional routing of statistics to the job statistic 
log (based upon user desires, but constrained by 
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BINARY LOGS 


installation wlllingness -- via "table" 
information -— to divulge certain information) 


Since the statistics facility determines the log Into 
which a given statistic (for examples PIDFR data) Is to be 
placed (based upon an installation and CDC defined tabled, 
system and product implementors should not be concerned 
with which ltlog{(s) are used for "their" statistics. This 
mapping will be determined later. 


ZBe2erel Account Log 


Ze2eZelel PURPOSE 


The purpose of the account log is to hold accounting and 
billing information. This consists of resources and/or 
services us2?d,y "who™ used them and "who" to chargee The 
account log should be the only log needed for an 
installation to do billina. 


Engloeercing_Loa 


ZBe2e2e2el PURPOSE 


The purpose of the engineering log is to hold information 
regarding system hardware usage and errorse The 
engineering log should be the only log needed to perform 
hardware usage and error anlaysise 


3.2.2.3 Statistic Log 


Be2e2e301 PURPOSE 


The purpose of the statistic log is to hold? 
- detailed system workioad information 


- detalted system performance information (lee@es, the 
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way the system responded to the workload) 


Although sone of this information Is recorded in other 
logs» a separate log Is maintained in order to: 


~ keep other logs relatively "clean" or ortented to 
thelr own purposes 


~ allow possibly large amounts of data to be recorded 
in a compact binary form 


3eo2e204% Job Statistic_Loa 


3e2e20%-1 PURPOSE 


The purpose of the job statistic log is similar to that of 
the (global) statistic loa. The global statistic fog 
contains information regarding all jobs in the systems but 
may be read only by orlvileged programs / userse 
Individual users» howevery may wish to see information 
that is available about thelr own jobs. The job statistic 
log may be read by normal programs / users and contains 
information regarding a single joby similar to the "scope" 
of the ASCII job log. 


32262.5 Binary Log Conventlons 


Avoid the use of character datae Since each record type 
is pre-defined by a CYBIL record type definitions, there ts 
seldom a need to describe the various data fields with 
keywords or the likee 


Message type naming follows the naming conventions 
described in STIS section 344. 


Use the binary logging facilities for PIDFR data. 


See the OS ERS and the SIS Usage Statistics section for 
minimum list of [items to be logged. 


Additional conventions will be added as design proceeds, 
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303 LISTARBLE OUTPUT 


When a significant amount of information is to be returned 
to the users it is written to a "listabie output file™. 
The standard format of such a file is dascribed here. 


CYBER 180 Output Standard Is defined in terms of: 
* Dutput File Organization — 

° Listing Page Layouts 

° Page Header Format 

° Format of Each Listing Type 

» Dbject Code and Debug Code 


3e3e1 LISTING PAGE FORMATS 


In the sections that follows the contents and format of 
the standard listings produced by CYBER 180 Products are 
defined in tarms of a vertical and horizontal layout. 


3-3.1.1 VYertical_Layout 


Vertical layout is defined in terms of the first printable 
fine of a form following top-of-form positioning by the 
printing device. This position is defined as tine 1 of a 
form and is reserved for the first print line of the 
standard listing header. The product is not responsible 
for the physical alignment of tine 1 reiative to the 
perforated fold on fan-foid printer forms, This is the 
responsibillty of the user on printers with vertical 
positioning carriage tape mechanisms or the responsibility 
of the CYBE2 180 9S Device Software on printers without 
vertical carriage mechanismse 


When the tast printable tine of a form has been written» 
the product will reset the page tine counter to 1. When 
the page line counter is equal to l» the next print line 
written is preceded by a standard listing header with a 
top-of—form code in the first character position of the 
header print record. The product is not responsible for 
the physical alignment of the last printabite line relative 


CYBER 
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to the perforated fold on fan-fold printer forms. 


323.1.2 Eormat_Attributes 


Zedele2el 


Each product must obtain the output file attributes from 
the operating system at the time the file is opened. 
These attributes include print modes page widths connect 
statuss page Formats and page length.» Vertical and 
horizontal print density have operating system defined 
defaults which may be changed by the user. 


Dutput files may be either continuouss which has a line 1 
position but does not have a last dine positions or 
paginated (none-continuous)»s which has both a line 1 
positions and a last line positions. Continuous form 
specification filles are intended for users using 
interactive terminals (display or hard-copy) for tistable 
output. Paginated (or "fan—fold") Jtistings are intended 
for users using line printers for listable output. 

For paginated files, page iength minus the number of tines 
of header determines the available lines per pagee The 
operating system provides a (defauit) standard page length 
of 66 lines per page at 6 lines per inch 

vertical print density. This provides an 11 Inch form 
jength. Print mode specifies whether or not the paginated 
file is “burstable"™ or "non—burstabie"™»s with 
"non-burstable™ being the default. 


A continuous form file is detected by checking the file's 
attribute page formate Connected files will default to 
continuous form modes but users may override this by 
specifying a page length for the connected file. 


CONTINUOUS OUTPUT FILE 


When formatting listable output for a continuous forms the 
product uses a standard tripleespace code in the first 
character position of the line 1 output record (usually 
the first line of the heacer) to achieve top-of-form 
positioning. Products will reformat listings for terminal 
users when requlred by this standard. 


Each type of listing (source Listings attribute Listings 
etce) is preceded by a triple=-space and the usual header 
Jine(s)»s but there is not pagination as such. 
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323012222 PAGINATED OUTPUT FILES 


When formatting output for paginated listingss the product 
uses a standard top-of-form code in the first character 
position of the line 1 print record (usually the first 
line of the header) to achieve top-of-form positioning.» 

In burstable listing modes each type of listing produced 
by the product (source listings attribute listings, etc.)) 
begins at a too-~of-form position. In non~burstable mode 
(sometimes refarred to as “paper saving” mode)» each type 
of iisting Is preceded by a triple-space and the usual 
header tine(s) if "proper space” remains on the current 
page. "Proper space™ Is defined as 6 plus the number of 
header lines (insuring that at least 3 lines of output can 
be pJlaced at the bottom of the page); if "proper space” 
does not remains the tripie space is replaced by a 
top-of-form. The source listing always begins at 
top-of-forms and user-specified page ejects (via 
compilation directives) always result in a top-of-form 
Fosition unless the listing is aiready positioned there. 


3.3.1.3 Standard Carriage Control Codes 


Carriage control characters that are used should be 
restricted to the following set: 


Character Action 
biank Space verticaily one line then print. 
0 Space vertically two lines then print. 
- Space vertically three lines then print. 
1 Eject to the first line of the next page 


before printings 


+ No advance before printing; allows 
overprinting. 


This set represents the full extent of compatibility 
between current CDC usage and the proposed ANSI standard, 


Under NOS 180» horizontal print density and 
vertical print density are file attributes that the user 
may modify, The NOS» NOS/BE carriage control! codes S$ and 
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Twili not be used te set or ciear the 8 lines per Inch 
mode. 


It will be necessary to make some provision for selection 
of print density when NOS 180 print files are to be 
printed by NOS or NOS/BE. The first release of NOS 189 
will depend entirely on 176 state for print files. 


3230124 Horizontal Layout. 


Horizontal tayout is defined in terms of output line 
character positions (columns) for a standard 132 cotfumn 
lines the “wide™ formate At a default 

horizontal print density of 16 characters per Inch the 
standard printer paper is assumed to be 14 Inches wide. 
Products are r2@quired to support a format consistent with 
the standard terminal lines the “narrow” format. This is 
defined to have 72 columnse Products are aiso required to 
support a format consistant with terminals with a capacity 
greater than 72 columns. The two other widths speci- 
ficaily supported on terminals are 86 column and 132 
column formats (where 132 coiumn format is a shared 
formats usually associated with hard copy). Formatting 
for other fine widths In addition to the standard terminal 
line is permitteds and will be referred to as "other 
formats.” 


Character position 1 of an output record is interpreted by 
the output device software as vertical positioning contro! 
and is never printed (displayed), Character positions 2 
thru 133 of an output record contain printed (displayed) 
characters, Column 1 of an output tine is character 
position 2 of the output record. 


3.2321.5 Standard Listing weader 
All CYBER 189 Products will use a standard 2 tine page 
header format on alld ftistings produced by the products. 


Through this sactions date and time fields conform to 
standards defined in section 4ele 
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If the line width specified is other than 72,9 86» or 132,» 
the heading will be mapped to one of the three standard 
listing headers. Other output will honor the actual line 
widths, untess specifically column orlented throughout the 
line {as opposed to column oriented for the first portion 
and open ended for the last portions such as source}. 


Line 1 of the scommon page header contains the following 
fieids (field definitions are in COBOL format): 


System Name x8) Operating System name. 


Product Name x(8) The longhand form of the 
product name@y i«@ey FORTRAN 
FMU, BASICs etce 


Product Version 9.99 Product version number. The 
number after the decimal 
point is shown left 
Justified» 3.2. 5.21» not 
5.01. This number Is updated 
at the product source code 
level by the responsible 
development organization for 
each new version release. 


Product Level Z2229 Product PSR modification 
level contained within the 
product itseif. This number 
is updated by the build 
procedures for each new 
update release. 


Instal! Date 99999 Ordinal Dates In YYDODD 
formats when product was 
added to the library, The 
date is obtained from the 
CYBER 186 OS using a standard 
Program Management request. 


Listing Name x(14) Name of the particular 
listing being produced. The 
acceptable listing names are 
defined in the following 
sections which define the 
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format of each fisting type. 


Module Name x{31) Name of the source module 
being compiled or the name of 
the input file being 
processed. The module name 
is obtained from the module 
identification statement 
provided within the languages 
ors the default name provided 
the product when an 
identification statement is 
not used. This name need not 
appear in the first page 
header if unobtainable. The 
name will appear feft 
Justified within the field if 
shorter than 31 characters. 


Date: x (18) Date at the time the first 
header was written (listing 
Page Number reset to 1). The 
date is obtained from the 
CYBER 186 OS using a standard 
Program Management request. 
The date format will conform 
te the standard given in 
section 4.1. 


Time: x(12) Time of day at the time the 
first header was written 
(listing Page Number reset 
to 1). The time is obtained 
from the CYBER 180 OS using a 
standard Program Management 
request. The time format 
will conform to the standard 
given in section 4.1. 


Page Number 'PAGE' 2229 Integer number generated by 
the product starting at 1 and 
incremented by 1 for each 
page header written for a 
compilation unit. The page 
number is reset for the first 
page header written for a 
compilation unit. This field 
is omitted from the standard 
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header when a continuous form 
is specified, The two parts 
are always separated by one 
biank,. 


34322 FORMATS 
Three logical tine width listing formats are generated by 
products: 
- Page Formatted Iines of 132 characters 
- 80 Column Formatted Lines of 80 characters 


- Narrow Formatted lines of 72 characters 
3032201 Wide Eormat 1132 columns) 


A standard header wil! be written at the top-of-form 
position of a listing whenever the page line counter is 
reset to 1 except when a continuous form is being 
written. A standard header will be written only at the 
beginning of a listing when a continuous form is 
specified. <A specified page width of 132 or greater will 
result in the following heading line. 


FILE CONTENTS LIST = WIDE FORMAT 


Columns 1-14 Listing Name or Columns 1-46 
program name 

Columns 16-46 Module Name 

Columns 48-53 System Name 

Columns 55-(54+n) Product Name (fength=ns n<24) 


Columns (564#n)-(59+#n) Product Version (length=4) 


Celumns {614n)-89 Product Level (tengthe5» biank 
filled) 


Columns 91-108 Date {right justified} 
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3 3e2el Wide Format (132 cofunns} 
Columns 110-121 Time {right justified} 
Columns 123-132 "PAGE! and Page Number {right 
Justified} 
All unspecified columns contain blanks. 
FILE CONTENTS LEGIBLE — WIDE FORMAT 
Columns 1-14 Listing Name or Columns 1-46 
program name 
Columns 16-46 Medule Name 
Columns 48-53 System Name 
Columns 55=78 Product Name 
Cotumns BO-83 Product Version 
Columns B5=39 Product Level 
Columns 91-108 Date {left justified} 
Columns 110-121 Time {left justified} 
Coiumns 123-132 PAGE and Page Number {left 
Justified} 


3e3.2.2 Narrow Eormat.(82_ Columns) 


The product will reformat the standard page format for a 
89 character line. <A physical output Jine format 
greater than the specified ttne size may be right-end 
truncated by the product to the required specification. 
The excess characters will appear on the next line. A 
product may choose to reformat narrow listings within 
the provisions of this document. 


The header format fon terminal formatted tistings} 
consists of two consecutive lines containing the flelds 
defined above in the following positions on tines 1 and 
lines 2. The PAGE and Page Number fieids are optional 
for continuous Files. 


This Informatlton will appear within the following column 
positions of the first print line (Product Names Product 
Versions and Product Lavell are jieft justified, separated 
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by one blank column): 
FILE CONTENTS LIST 
Line 1 
Columns 1-14 Listing Name 
Columns 16-46 Module Name 
Columns 48-65 | Date {right justified} 
Columns 70-89 Page {right justified} 
Line 2 
Columns 1-6 System Name 
Columns 8-{7=-n} Product Name {length=nsn = 24} 
Columns {94n} = (12+4n} eoauct Version {length = 4} 
Columns {14+n} - 42 Product Level Clength=5» blank 
Fill} 
Columns 48-59 Time {fright justified} 
FILE CONTENTS LEGIBLE - 86 Column Format 
Line 1 
Columns 1-14 Listing Name 
Columns 16-46 Module Name 
Columns 48-65 Date {left justified} 
Columns 70-89 Page fieft justified} 
Line 2 
Cofumns 1-6 System Name 
Columns 8-{7=-n} Product Name {length=ns n=24} 
Columns (94+n}-€12+n} Product Version {length=4} 
Columns {€14+n}-42 Product Level {length=5 blank 


Fill} 
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Cofumns 48-59 Time {left justified} 


32322.3 Nacrow Eormat.(72_colums) 


The header format (on terminal formatted listing) consists 
cf two consecutive lines containing the fields defined 
above in the following positions on Lines 1 and 22 The 
PAGE and Page Number fields are optional for continuous 


files. 
FILE CONTENTS LIST 
Line 1 
Columns 1-14 Listing Name 
Columns 16-46 Module Name 
Columns 49-69 Time {right justified} 
Columns 62 "PAGE' and Page Number {right 
Justified} 
Line 2 
Columns 1-18 Date {right Justified} 
Columns 29—25 System 
Cojumns 27-(26+n) Product Name (length=nys 
n<24) 
Columns (284+n)-(31+tn) Product Version (length=4) 
Columns (33+n)-61 Product Level (length=5,5 


blank filled) 


FILE CONTENTS LEGIBLE — NARROW FORMAT 
Line l 


Columns 1-14 Listing Name or columns 
1-46 program name 
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Columns 16-45 Module Name 

Columns 49-69 Time {left justified} 

Columns 62 "PAGE! and Page Number 
Cieft justified} 

Line 2 

Columns 1-18 Data {ieft Justified} 

Columns 20~25 System 

Columns 27-89 : Product Name {left 
justified} 

Columns 52-55 Product Version {Jeft 
justified} 

Columns 57-41 Product Level {left 


justified} 
323.23 SQURCE LISTING FORMATS 


The following standard appities to compilerss assemblers 
and interoreters. Assembiers may optionally Insert binary 
information at the left of the source statement. Page 
ejects may be suppressed for subsequent listings of each 
module (e.g. Maps Cross reference) if the source Jisting 
is short (e.9. 1/2 a page or less). 


The number of records in the source file should be the 

same as the number of source Jines in the source JIste 

Therefore, null records should be mapped to all blanks. 
(See section 26342084) 


3e3-3.1 Standard Header_Contents 
Every printable source listing contains the following text 
in the Listing Name fleld of the standard Jisting header: 


SOURCE LIST OF 
—-—14 characters-- 


A standard source Wtisting header willl be written at the 
next top—-of-form position whenever the page line counter 
is reset to 1. Oniy the first source listing header will 
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be written on a continuous forme 


3032302 TLTILE Lines 


When source embedded TITLE or SUBTITLE directives are 
processed, the page line counter is reset to 1 anda 
standard header Is written. The title text Is printed 
beginning in column 25 and ending in column 132 of the 
line immediately following the first line of the standard 
header. The title lines are followed by a blank line. 


standard haader -— line 1 
title text -~- jine 2 
subtitie text “~~ line 3 ~- 11 (if any) 
blank ~~ line n 


n may take the value 3 to 125 depending upon the 
presence of a subtitie lines. 


When a source listing Is being formatted for a continuous 
forms, the title line Is simply preceded and followed by a 
single blank tine. 


If a SUBTITLE occurs without a TITLEs a blank line is 
placed in the position which would have been occupied by 
the TITLE. 


When the source Input module does not contain a TITLE 
directives two blank lines immediately follow the second 
line of the standard Jisting header. 


323-323 wide Eormat 


The actual source statement Listing begins on the line 
following the blank Jine following the headers or titles 
if present. Each source Jisting print tine contains the 
following optional fields: 


Offset 2(8) A zero suppressed hexadecimal 
number (see section 3.1) giving the 
byte offset in code section of the 
first instruction generated for the 
listed source statement. If this 
fieid is supported, it is selected 
by the fist option 80. If 
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Input Line 


selected, the field must be 
supplied for ail source fisting 
lines. 


line. See 


Number Z{10) A numericy zero suppressed numbers 
up to 16 characters in length» 
allocated to the source 
section 243. 

Left Statement . 

Attributes x(4) Language dependent attributes. 

Right Statement 
Attributes x(4) Compiler dependent attributes. 


The Source Record 
is a required Field 


Source Record 


x(132) 


Up to the first 132 characters of 
the Input source record. If the 
source line Is fess than 132 
characters, this flieid is left 
Justified. Source Code Utility 
(SCU) identifiers are contained 
within this fields If they exist. 


If all fieids were present in a source Jistings column 
positions would be? 
Columns 1-8 Vffset 
Columns 10-13 Left statement attributes 
Columns 15-24 Line number 
Columns 26-125 Source (including SCU 
identification when present) 
Columns 127-130 Right statement attributes 


If an optional fletd tis not used the remaining fields will 


be adjusted to the jJeft. 

when the source record (26-125) 
identification 
will 


includes 
information the following 
be adhered to for the source record 


26-105 Source 
107-125 SCU identifier. 


Columns 


The fields should not be changed (mixed) 


SCU 
column positions 


between 
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successive uses. Once the fields desired are established 
they must remain unchanged. 

Existing Filelds before and after the source record may be 
blank. If the source record overflows an additional tine 
is written within the source record field. In this case 
the right attributes field of the first line contains 
*.ee' as the first three characters and the rest of the 
Field and offset field are blanke The overfiow line 
contains blanks in the line number field and the remainder 
of the source record left justified in the source record 
field. The right attributes Field contains the 
information which would otherwise have appeared in the 
first tine, 


3.2323.4 Narrow Eormat_and_80 Column_Eormat 


The source listing format written on a terminal formatted 
fisting consists of one or more output tines for each 
input source record. 


The first line consists of the following fields: 


Line Identifier Numeric right justified teading 
zeros suppressed. Optional 
variable width field up to 106 
characters. 


Seurce Record The source record field size is 
dependent on the file attribute 
maximum record ftength and the size 
of the line number field. 


A single blank separates these two fields. 
The source record field size is dependent on the file 
attribute maxinum record ftength. 


If the source record is longer than the Source Record 
field then an additional Line is written. The lines are 
printed with the same format containing blanks in the Line 
Number field and the remainder of the source line 
left-justified in the Source Record field. 
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323-64 OBJECT CODE LISTING FORMAT 


This is the format for listing lines of object code 
produced by the compilers at the users request. 
Assembiers Ttist their source tines formatted as submitted 
from the input file. 

The object code tisting shali take one of two forms. The 
first consists of lines describing each CY180 instruction 
embedded in the source ilsting ands as far as possible, 
following the same fine from which the code is generated. 
The object code Jine shali conform to the standard defined 
below. A grouno of object code listing lines shall be 
preceded and followed hy a blank fine. 


In the second forms the fines describing the object coday 
also conforzing to the standard defined belows are 
collected into a separate listings the "object code 
listing” which shall conform to a page format common to 
the listings produced by all compilers. This is defined 
as follows. 


OQbject code listings consist of instruction descriptions 
and comment tines. 


Instruction Description 


With the exception of BDP instrucionss, each Instruction 
emitted is described by a single print tine optionally 
preceded and/or followed by comment lines. The 
instruction description will contain the following fields 
in the following orders beginning in column 2 of the 
listable output. 


Offset Z7{8) A zero suppressed hexadecimal number 
(see section 3.1) giving the byte 
offset of the instruction relative to 
an implementation defined base. This 
base shal! be the same base used in 
the offset field In the source fine 
(if provided.) 


X(1) 


Input Line 
Number 277729 The number of the input line for which 
the cede Is being generated (as far as 
is practicable). 


3-25 
CYBER 1260 System Interface Standara 
poate itet 
36 9 QUTPUT 
ae7s 4 sheesh CODE eISTaNs FORMAT 


Binary X(20) An 4» 8 or Llb-digit hexadecimal number 
: {adjusted to the fteft) representing 
the binary bit pattern corresponding 
to the generated instruction or data. 
For readability the suggested form is 
to arrange the numbers In groups of 4» 
separated by blanks. The 4 and 8 
' digit numbers are followed by blanks 
toa complete the field. For narrow 
formats this field will not be present. 


X(2) 


Label X(31) A 1 to 31 alphanumeric character 
string identifying the instruction 
fabel as defined for the CYBER 180 
assembler. The label fleld can be up 
to 31 characters in tengthe. It can be 
used in an implementation manner in 
conjunction with the comment field. 


X(2) 


Instruction X(10) A character string identifying the 
8{3) Instruction and its operands. The 
X(21) mnemonics to be used are those defined 

for the CYBER 180 assembler. The 
mnemonic identifier only may be offset 
by 2 or 4 spaces to distinguish 
particular Instrucions or instruction 
sequencese (@ege to identify code 
generated out of sequence with the 
source.) Operands are specified in 
the order defined in assembler 
specification which appears in an 
Appendix (to be supplied). As shown 
In the format descriptions, the 
breakdown of the instruction is as 


follows: 
MNEMONIC X(190) 
X(3) 
OPERANDS X(21) 
X¢(1) 
Comment X(25) An implementation dependent field 


typically containing user variable or 
fabel identifiers register use 
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The narrow format and 86 Column Format consist of the 
offsets tine numbers labels» mnemonics operands and 
concatenated fields. The binary fieid will not be 
present. If the listed line exceeds 72 or 80 columns the 
line will be continued on the next line (called 
"folding™). For PN other than 72 or 80s the actual width 
specified will be honored; excess information will be 
folded. 


Bdp Instructions 


These are described by a jline formatted as aboves followed 
by one or two descriptor descriptions. These are similar 
te the instruction lines except that the mnemonic field is 
blank and the operand fieid contains a descriptor In the 
form defined by the assembler specification. 


Comment Lines 


These are used to convey more information than can be 
accommodated in the comment field of an instruction 
description. They consist of a comment field as defined 
for the instruction descriptions 


3232%.1 Standard Header Contents 


Every printable object code listing contains the following 
text in the Listing Name field of the standard tisting 
header: 


OBJECT LISTING OF 
--20 characters-- 


A standard object listing header will be written at the 
next top-of-form position whenever the page line counter 
is reset to le Only the first object listing header will 
be written on a continuous forme 
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323-4%.2 Standard Instruction Mnemonics 


The instruction menmonics used by the compilers will be 
those of the CYBER 189 assembler. 


36365 ATTRIBUTES LISTING FORMAT 


A common format for the Attribute/Cross Reference listing 
Is defined here. It Is useable by all? currently planned 
langueges for the Cyber 180 and provides enough 
flexibility to tallor portions of the listing to 
individual language needs, 


The content of the Attributes Listing will vary slightly 
depending upon whether Cross References were selected or 
nots but the essential format will be the same. If the 
user selects both attribues and references, the normal 
format will be used. When references are not setecteds 
the heading will reflact the differences but the format 
wili not vary. Uf references are selected, but not 
attributess then some of the attribute information 
provided will not be listeds providing some additional 
space for raferences on the line. 


3e3e5el Standard Header Contents 


Every printable attribute listing or attribute/cross 
reference listing contains the following text in the 
Listing Name field of the standard tisting header: 


ATTRIBUTES OF 
“---14 characters-~--- 


If no attribute list Is selected (cross reference selected 
only) the following text is placed in the Listing Name 
fieid instead? 


REFERENCES OF 
w--14 characters---- 


A standard attribute list header will be written at the 
next top<of-form position or following a triple spaces as 
specified by sections 34361e2e1 and 3e3ele2e2» and 

whenever following page breaks occure Oniy the first 
attribute list header witli be written on a continuous form. 
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The standard header Is followed by a blank IlIne and one or 
more lines containing the attribute/cross reference 
listing heading.» This consists of the field descriptions 
as defined in the next sectionss separated by one or more 
bianks. Numeric fields In the listing are right-aligned 
with the right-hand side of the description; character 
string fields are aligned on the lefts where appropriate. 
Some of the field descriptions may be split between two or 
more lines if requireds, or omitted, if necessarys as 
indicated below. 


323.25.2 Wide _Eormat 


The fisting is made up of entries describing the objects 
defined jn the source program. Each entry consists of a 
definition lines followed by one or more extension fines 
if required. The definition line gives the tine In which 
the object was declared (or first referenced if implicitiy 
declared)» the identifiers and attributes. Extension 
lines are used Jf there are more attributes than can be 
accommodated on one lines and to hold references If 
selected. If both attributes and references are selected, 
the references always hegin on an extension tine by 
themselves. 


Tha lines contain the fieids described in the table below,y 
in the order specifjed. The table also contains the field 
description to be piaced in the table heading. The final 
section of the line (for host supplied free form 
attributes and the references) is continued on extension 
lines as necessary. 


Entrles occur In alphabetical order with a blank line 
inserted between groups of Identifiers starting with the 
same character. Multiply defined identifiers are 
consecutive In order of Increasing level of nesting or In 
order of occurrence of block. 

Variable format fields are optional. They are in the 
indicated order if useds otherwise the field is not 
present. The sizes for the given fleids are maximum width. 


ATTRIBUTE/CROSS REFERENCE LISTING FIELDS 


Fixed Format: 


Fieid Heading Size Meaning 


identifier IDENTIFIER X(31) The identifier of the entity. 
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323-522 Wide Format 


biank 


definition DEFINED 
ON LINE 


blank 


size SIZE unit 


X¥(1) 


The name appears jieft justifieds 
blank filled. 


The source line number in which. 
the entity was defineds or (for 
languages with Implicit 
definitions) first usede It may 
extend Into the identifier field 
if larger than five (5) digits. 
The second tine of the heading 
-~ON LINE= appears oniy in the 
wide format. 


Size of the entity» in unitss 
defined by the host (either bits» 
bytes» or words). The units of 
the size of the entity wlll 
appear as "RIT", “"BYTE™, or 
"WORD". Abbreviations are BIT» 
BYTs WRD. Normally the fields 
for size unit combination will be 


size Z{8) 
biank X(1) 
unit X(4) 


If the size field exceeds 8 
digitss then the fietds will be 


size Z(10) 
unit X{3) 
Special case: 


If size units is no-sizes then 
the size fleld is allowed to be a 
signed integer (54=-bit). This 
will be right justified under the 
SIZE titie If possible. If it Is 
too farges, it “grows” to the 
right. If it is so targe as to 
grow into the TYPE fields the 
TYPE field Is pushed to the 
righte This is possible because 
the LOCATION fietd is undefined 
if the SIZE units are nomsize. 
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biank 


type of 
entity 


biank 


location 


TYPE 


LOCATION 
SEC 4+DFF 


X(10) 


X{1) 


Minimum 
X{6) 


The type of the entity being 
jisted. Chosen from the list in 
section 32£325+4.13 if the host 
wishes further qualifications 
jisted they appear in the 
attributes fist. 


The focation of the entitys 
where "SEC™ is the section name 
of the section containing the 
data for the identified 
references and “off" is the 
offset to the beginning of the 
section. The section names are: 


S$LITERAL The section 
containing ftiteral 
constant data. 

STACK The section 
containing variables 
that are allocated 
on the stack when 
the containing 
procedure Is cailed,. 

ZPARAMETER A subset of the 
S$STACK section 
containing parameter 
fist varlables 
allocated on the 
stack by the calling 
procedure. 

S$STATIC The section 
containing variables 
that are statically 
allocated», are not 
in commons and are 
not in an explicitly 
named section. 

SREGISTER Variables not 
belonging to any 
memory section but 
existing only in a 
hardware register. 

$BINDING The binding section. 
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SBLANK 


CYBSDEFAULT 


HE AP 


Blank (unnamed) 
commone 


The system heap. 


Code section names will be set to 
the name of the procedure the 
section represents. User defined 
names of section and user 
declared common blocks wlll also 
be specified In full (up to 31 


characters). 


when a “sec™ name is too large to 
fit into the default field size 
allocated, the entire name is 
printeds expanding to the right. 
A line feed and re-alignment 
"™"back™ to the next listing field 
allows continuation of cross 
reference data generation. For 
narrow format (section 3432543)» 
if the "sec™ name does not fit on 


the lines 
next line by 


it will be put on the 


itselfs, then the 


rest cf the map will continue 
following a line feed and 
remalignment to the next field. 


Variable Format 


For narrow or 80 column format listing the variable format 
fields continue on a new tine beginning in column 15 and 


extending to column 70 or 80. 


For wide format listing the 


variable format flelds contInue on the same tine beginning 


in column 75. 


Field Heading Size Meaning 

block number BLOCK 2999 Specifies the block or subroutine 
in which the object was defined. 

blank X(2) 

nesting NEST 7ZZ9°9 §=The nesting level of the 

leve! LEVEL deciaration of the entity if a 


block=-structured language. If 
the host Is not a biock 
structured tanguage, the nesting 
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fevel Is omitted. The second 
line of the heading - LEVEL = 
appears only in the wide format, 


blank X(2) 


containing CONTAIN QR X(31) The name of the containing or 

entity DECLARED IN qualifying entity. Blank if the 
entity is not contained or 
qualified. The “contained 
within™ form is for arrays and 
structures. The "deciared in" 
form is for local variables. The 
entire heading is on one line. 


blank X(2) 


basic ATTRIBUTES X(12) The "basic attribute” of the 

attributes entity (entrys externals etc.) 
chosen from the list in section 
Zeredetele Biank if 
non~applicable to the entity. If 
there are no optional fields and 
the basic attribute is not 
presents the whole line Is 
omitted in narrow format. 


user inc heading) free Qther host defined attributes 
attributes field separated by commas. These 
start- attributes begin on a 
Ing on separate line beginning with 
a sepa~ column 54 for wide format and 
rate column 15 for narrow format 
line Jistings. Each definition 
specifled by the host is placed 
on one tine if possible, 
otherwise each that overflows 
starts anew line. If the 
definition doesnitt Fit alones it 
is broken at a blank, 


references REFERENCES 7(6)X(2) References on the’ identifier 
For combined fine begin at column 54 on. 
Maps, subheading the listing In narrow format 
will be the first line has two 
references. Subsequent 
MREFS™, fines start in column 15 
starting on and have six references per 


a separate fine. In wide format all 
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linee lines start in column 54 and have 


8 references per linee For mixed 
mode tistingss see discussion 
below. 


The format for references is a six digits right 
jJustifieds blank filled integers followed by an 
opticnal slash (/)» followed by qualifying ietter, 
chosen from the list In section 3432524232 This 
combination is followed by a blank. 


In mixed mode (combined attributes and references)» 
both the attributes and references are handied as 
described aboves except that the first reference line 
has a subtitle -REFS- placed at Its left. The subtitle 
~REFS= is placed in columns 9-13 on the narrow listing 
and in columns 48-52 In the wide listing. 


Since the user may select the attributes tisting 
separate from the references listings the following 
changes occur when both are not selected together. If 
attributes only are selected» the references are not 
listed. If references only are selecteds the 
identifiers line number and references fields are used 
and the references begin at the end of the first lineysy 
not on an extension tine. 


3632523 Narrow Eormat_and_39 Column _Eocnpat 


The narrow format listing willl have the same format as 
the wide listing with the exceptions noted in the 
describitions In section 34232522 and with the 
exception that the attributes and refernces fields will 
continue on an extension tine beginning in column 15 
and extending to column 70 or 866 


323-5464 Standard Eleld Values 


303050401 ENTITY TYPES 


Each entity is assigned a basics cross-language type. 
These appear In the "Type" field as one of the following; 


TYPE ABBREVIATED FORM 


Simple vars VAR 


CYBER 
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Arrays ARR 
Structure» STRU 
Member» MEM 
Conditions COND 
Constants CONS 
Type, TYPE 
DEF» DEF 
Programs PROG 
Module MOD 
Procedurey PROC 
Functions FUNC 
Labels LAB 
Switchs SWCH 
Files FILE 
Formats FMT 
Paragraph» PARA 
Sections SEC 
Imp! nama, (for Implementor name) IMPL 
Groups GRP 
Aljas ALIA 
Error ERR 
Attr namey ATTR 


Each host need not support ali types of entities on this 
lists but should define a consistent mapping into a subset 
of the above, The final entry ("Error") should be used 
for entities whose definitions contain syntax errors 
sufficient to erevent the complier from determining the 
user's intentions. 


BASIC ATTRIBUTES 


This field contains attributes basic to the entity 
definition which are exclusive of one another. If the 
entity does not fall Into one of the following catagories 
of attributes, then the field is teft blank. These are: 


Attribute Abbreviated Form 
undefined UNDEF 
unreferenced UNREF 
EntryPotint ENTRY 
External EXTRN 


None (field Is blank) 
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303050403 REFERENCE TYPES 


The os reference type abbreviations will be: 
the entity was set (modified), 
ors the antity was used (slash is also omitted) 


A the statement defined an entity attributes 

$ the entity was a subscript or indexys 

I the entity (usualtly a fille) was referenced In 
an 1/0 statement 

R the entity was read into (ors if a files was 
read) — 

W the entity as written from (or, if a files was 
written) 

P the entity was used as an actual parameter 


For all listings containing references there Is a legend 

of the possible reference types and their one character 
abbreviations at the bottom of each page. This legend is 
right Justified and takes the form abbrev = full names esses 


For example: M=moedifys» Az=attributes S=subscripts 
T=I/0 refs 22reads Wawrites P=param. 


Each host may choose to use the entire set or a subset 
thereof, but it Is hoped that most hosts will use the 
entire set. 


323.6 DIAGNOSTIC LISTING 


The diagnostic listing for compilerss assemblersys 
interpreterss etces cansists of diagnostic messages. 
Diagnostics are listed in either of two modesy at the 
host's choice. The first method lists all diagnostics and 
a diagnostic summary at the end of the listings following 
the Attribute/Reference tist (if selected). The second 
method lists syntax diagnostics In the source listing as 
they are detected» with later (none-syntax) diagnostics and 
the diagnostic summary being listed at the end of the 
Attribute/Reference ftist. If the First method Is 
selected, the host may also choose to have the jocation of 
the diagnostic occurrence flagged in the source listing 
(by means of a caret symbol under the offending column). 


When compilation occurs with zero diagnostics a diagnostic 
summary willl be produced consisting of the singie line ‘ND 
ERRORS?, 
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Every printable error Jlisting/summary contains the 
following text In the listing name field of the standard 
listing header? 


ERROR LIST OF 
m~m~m14 characters---- 


A standard error fisting header will be written at the 
next top-of-form position or following a triple spacey as 
specified by sections 363e1e2e1 and 3e3ele2e2s and 
whenever a subsequent page break occurs. Only the first 
error listing header is written on a continuous form. 


3o3e6e2 Standard Diagnostic Listing Format 


All diagnostic JlIistingss whether grouped together at the 
end of the other fistings or printed intermixed with the 
source listing wlil have the same basic format. When 
grouped, they will be listed in source line/statement 
column/diagnostic number order. When grouped and the 
diagnostic number is not being printeds they will be 
listed in source line/statement column/order of Issuance 
order. When printed Intermixed with the source listings 
they will] be printed in the order the host detects theme 


Column positions are specified for the case where all 
fields are used» and remain the same If an optional fletd 
is not used. 


Column 

Position Contents Format Meaning 

1-9 Jevel X (9) error severity tevel of the 
diagnostic 

11-17 line nre 2(6)9 source statement number on 


which the error occurred. For 
diagnostics intermixed with 
the source listings this field 
contains *ERROR*, 


22724 diag» noe 22799 diagnostic number of the error 
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(assigned by the host). This 
field is optional. 


26~-228 COL ¥{3) The abbreviation for the word 
column in intermixed mode. If 
the column number field 
contains zeros "COL? is 
suppressed, In grouped mode 
this field contains the column 
number described below, and 
that field is blank. 


320-32 col. no» 729 column number in which the 
error was detected. Blank If 
not applicable. In grouped 
mode the column number is 
present In the col (26-28) 
field and the column number 
field is blank. 


34-eo1. text the diagnostic text (defined 
by the host). Each word 
within the text is separated 
by one space and the tine is 
fllled as required. Extension 
lines begin with the text 
position through the end of 
the Lines single-spaced. In 
intermixed modes the *ERROR* 
indicator is re-issued on 
extension lines. 


Diagnostic summary for products that use diagnostics 
intermixed with source should include a page iist of pages 
with diagnostics. 


323-663 Standard Diagnostic. Summacy_Eormat 


The diagnostic summary will follow the diagnostic listing 
for grouped diagnosticss or stand-alone for intermixed. 
diagnostics. In either case it provides the user with a 
summary of diagnostics detected and listeds as directed by 
the EL parameter. 


There will be an diagnostic summary line for each level of 
diagnostic detected during the compilation. If no 
compilation errors {at any level) were detected, then that 
is noted. The following format will be used for all of 
the summary tines? 
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columns 3-6 * kK Summary tine flag 
columns 9-14 Number of diagnostics of a 
given categorys In the format 
Z(5)9,. 
columns 146-e0! Texts In the format “aaaa 


diagnostics", where aaaa is 
the category being . 
summarized. If the 
diagnostics were not listed 
{due to EL setting) then 
"(unlisted)" is appended to 
the message. 


If only one diagnostic at a given jevel was issueds the 
word "diagnostics" will be “diagnostic” in the messages. 


3e3e7 COMPILATION OPTIONS 


The compilers will produce one or more lines of output to 
indicate which control statement options were setected for 
this complie (elther by default or explicitly). The 
format of this line will reflect section 2.2 of this 
standard. This line will appear after all other listings 
for each module. It is produced whenever any list option 
is selected and not produced for LOQ=NONE. 


3e4 ERROR MESSAGES 


This section describes conventions for aii ASCII error 
messages. This Includes log messages (to system and job 
logs)», interactive messagess and error messages written to 
the QUTPUT or other files (reference logs» section 342). 
The conventions Include the use of the Message Generators 
message identifications and message wording. 


3e4%e.1 MESSAGE GENERATOR USAGE 


The NOS/VE Message Generator is used to format and output 
all error messages output to logs or to an interactive 
users terminal (note this does not Include dlagnostics 
generated during compilation). It produces a standardized 
message using the NOS/VE status record and message 
templates fron a message dictionary. 
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A summary of the NOS/VE status record fields is noted 
below. The NOS/VE ERS should be referenced for a complete 
cescription of the status record and the Message Generator 
interfaces. 


Normal ~ A boolean which has a value of FALSE If a request 
could not be processed correctiy and TRUE if it has been 
processed correctly. 


Identifier - The two character product identifier 
associated with the oroduct generating the status record, 
The identiflers are as defined in sections 4e12e1+1 and 
3e4e121 of this document. 


Condition ~ A six digit unique system wide code indicating 
the specific error. The values for this field are defined 
by each product according to the conventions specified in 
the following section. 


Text ~ A string used to substitute text into the error 
message temolate associated with the condition. The first 
character of the text signifies the character used as the 
text delimiter. Al} text items are terminated by the 
delimiter or the end of text. 


3e4.1.1 Standard Condition.Codes 


To guarantee generation of unique system wide condition 
codesy a range of numbers are assigned for each product. 
Each product must assign codes within that range and 
determine the message template to be associated with that 
code. Product Identifiers are as assigned in 

section 4.1.1.1 and are repeated below. 


Ali CCM and CCG errors will be reported using host 
condition codes. The codes to be used are chosen by each 
host. A host nust provide at tleast 256 condition codes 
for reporting CCM errors and 250 codes for CCG errors. 
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Condition 


1 
160s009 


170,000 
180,000 
190000 
2002060 
2105699 
2203090 
2300909 
2409000 
2509000 
260,009 
2709000 
28929000 
2902009 
3003000 
310,000 
3205000 
3309009 
3409909 
3602000 
3609 906 
3799009 


3809000 


Code 


129,999 
1695999 


1799999 
1293999 
19939999 
2099999 
2199999 
2293999 
2393999 
24939999 
2599999 
26939999 
27939999 
2899999 
2999999 
3093999 
319,999 
3299999 
3399999 
34953999 
3599999 
3699999 
3799999 


4993999 


Product 


Identifier 


Reserved 


AM 
26 8 
JM 
LL 


MM 


CM 
HU 


NA 


Reserved 


Product Name 


Basic Access Methods 
Command Language 

Job Management 

Loader 

Memory Management 
Operating System 
Permanent File Management/File System 
Program Management 
Resource Management 
Gperator Facility 
Accounting/Validation 
Interstate Communication 
Remote Host Facllity 
Object Code Utilities 
Deadstart/Recovery 
Maintenance Services 
Interactive Facility 
User (e.ge»s for “user™ statistics) 
Statistics Facility 
Configuration Management 
Help Utilities 


Network Access Method 
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5009900 
5102009 
5203000 
5305900 
5409600 
3599000 
5609009 
5702009 
580009 
585,090 
396,900 
6002909 
41090090 
6299900 
6302009 
6405909 
6505009 


6609090 


670009 
580s 0090 
6909099 
7009000 
7109 060 
7209009 


5099999 
2199999 
5299999 
5399999 
2499999 
9599999 
2699999 
97939999 
2649999 
2899999 
2999999 
6099999 
6192999 
6299999 
6399999 
6495999 
6599999 


6693999 


67939999 
68939999 
699,999 
7093999 
11939999 


7293999 


Codes 


Advanced Access Method 
Edit Screen | 
Assembly Language 
APL 

BASIC 

DCN Dump Analyzer 
coBoL 

CYBIL 

FORTRAN COMPILER 
FORTRAN LIBRARY 
PASCAL (Wirth) 

PL/I 

Sort Merge 

Source Code Utility 
FMU 


Debug Facility 


Hardware Performance Analyzer (HPA) 


Maintenance Application Language 


for Equipment Testing (MALET) 


Math Library 


Information Management Facllity 


Software Tools 
LISP 
File Migration Aids 


Ada 
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730,000 ~ 7399999 FY COC FORTRAN (Vector izing) 
7499009 - 7499999 yc C compiler 
7509009 = 7599999 VX VX/VE - UNIX Emulator 


Se4e2 MESSAGE TEXT 


The message templates are determined by each product and 
included In a message dictionary. The NOS/VE ERS should 
be referenced to determine the formats of message 
templates. 


324.221 Message Formats 


The message generator formats and outputs messages 
according to conventions based on the messagets 
destination: terminals logs files or raturned to the 
caller. 


Terminal: 


Format: text esese or Tdnnannnan text eseeos 
Example? Permanent file (pfu) not found. 


Logs» OUTPUT» or other files 


Format: If0nnannan text esecse 
Example: CBO326 Incorrect delimiters comma 
assumed. 


Returned to caller: 


Format: TDnnnnnn SID) mmm text seese2e 
Example: AM1234 SOP 012 File (ifn) already 
openede 
Where: 

text eseex = Text of message 

Id = Product identifier 

annannn = The error condition code 
(unique error number for a given 
product) 

STD = Product subidentifier 

mmm = Subcondition code. 
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The combination TDnnnnnn will be known externally as the 
"C186 error number". Jt is a unique system-wide code by 
which any error message can be Identifled to the user. It 
is always printed before the message text on all batch 
listings. It can optionally be Inciuded with messages 
output to an interactive terminal and is availabie to the 
terminal user requesting additional error analysis 
assistance via the NOS/VE HELP facility. 


344.2.2 Error Summaries_in_Logs 
When error summaries are listed on a files log messages 
should be issued te both the system and user fog according 
to the following rules and formats: 
System and User Log 
n fatal errors [Cin x] 


User Log Only 


n warning or trivial errors Cin x] 
n number of errors 
Xx Is the name of the modules programs subroutine 


that contains the errorse 


Error summaries should onty be used when it is 
inconvenient to provide a description of an actual error, 


Catastrophic errors are not included because they shoutd 
always result in a log message indicating the catastrophic 
error. The error counts should be Issued to the log even 
if the EL (error level) parameter excitudes them from the 
listing. 


324.203 Message Wording 


Error messages represent a very importants, though often 
negiecteds Interface between software and usere Proper 
attention to producing polite, corrects, and clear error 
messages can do a lot toward improving the overall 
usability of the system. The following conventions should 
te used in defining error message text: 
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® Messages should be polite and courteous. Words such 

as “jljlegal® should be avoided In favor of words tike 
“incorrect” or "unknown". Error messages should, 
where appropriates suggest what the user ought to do 
to correct the error. For examples use: 

The line number parameter must be an Integere 
not: 

Tllegal tine number. 


* Messages must be formatted for 72 character displays. 
Telegraph style is much better than long-winded 
prose. However, the message must be descriptive of 
the error, Messages tike "Bad Argument” don't say 
enoughe 

* Consistent terminology is extremely important. For 
system-wide terms consult Section 6.90 of the SIS. For 
terminology specific to a products again consistency 
is the Important factor. 


a Identification must be provided with variable 
information. For example: 
use: 
Fite (lfn) not found. 
Variable (var) must be scalar. 


not; 


{ifn) not found. 
Variable (var) must be scalar. 


° Use anding punctuation. It Indicates to the user that 
the message Is not continued on the next tine and adds 
te the readability of the message. 


* Messages should he oriented toward an tnexperlenced or 
casual user such that the message can be understood 
and appropriately responded to without reference to a 
manual. 


F Abbreviations should be avoided. Whenever possibie 
limit the characters used to alphanumerics plus 
english punctuation. Avoid use of characters that 
appear differently on different devices. CDC's 
64—character ASCII subset and jJowercase alphanumerics 
can be used, 


° Words beginning with "multi" and “non™ are not 
hyphenated. Don't use "(s)" to Indicate an optionai 
plural usage; either singular or plural is acceptable. 
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* Error messages should use upper and lower case as they 


are normally used in the English language. Upper case 
should ba used to distinguish “computer™ words from 
normal English wordse For example: 


File FRED not found. Specify keyword NEW. 


305 USAGE STATISTICS 


All products are regulred to collect and fog statistical 
information. 


This section describes what these statistics are used fors 
the NOS/VE Statistics Facilitys which statistics will be 
collected by products and which will be coilected by the 
0/S and when statistics should be jogged. 


Because the Statistics Facility is under control of NOS/VE 
product desIgners ar2 requested to convey statistics 
requirements and plans to the NOS/VE design team. 


325.1 PURPOSE OF STATISTICS 


Statistics logged by products may be used for billings 
measuring retiabilitys measuring performances debuggings 
product planning or some other purpose. The ultimate use 
of the data cannot be determined when the product is being 
designed. For examples a statistic such as "number of 
source statements compiled", which is normally considered 
a performance statistics could Just as easily be used as 
the basis for charging or biliing a usere It's not 
inconceivable that a student could be billed based upon 
(number of source statements) — (number of comment lines) 
+n * (number of errors) if this data were avallable for 
each compile. 


There are three physically different logs for recording 
statistics. They are the accountings jobs and system 
statistics logs. See section 3422 <A particular statistic 
may apply to one or all three of these fogs. To prevent 
products from having to issue the same statistic several 
timess to prevent product designers from having to decide 
which statistics will be used for which purposes and to 
provide instaltations and users maximum control over 
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statistics gatherings NOS/VE provides a centralized 
Statistics Facillty. 


3e3e2 STATISTICS FACILITY 


NOTE: This Is pretiminary information. The NOS/VE 
ERS should be referenced for a more complete 
and up to date specificatione The ERS is the 
controlling document for this product to O75 
interface. 


The NOS/VE Statistics Facility is used by products and the 
QO/S to accumulate statistics and write records into binary 
1909S. 


The Statistics Facility 


- associates a statistic code from a status record with 
a particular table entry 


~- adds job and task identification to the variable data 
if appropriate. Task identification specifies which 
of the possibite several asynchronous instances of 
execution within a job the current statistic belongs 
to. 


- routes the statistic to the appropriate log or logs 
and/or adds it to a specific counter as determined by 
the table entry. Counters can be dumped to binary 
logs at specific times or events. 


Data passed to the Statistics Facility include: 


~ statistical code — ordinal of this particular 
statistic. 


- optional byte string - for products this string 
contains product %D» module identifiers if 
appropriates, and any other product or statistic unlaue 
descriptive data. Product ID is the two character 
identifier defined in section 4elele 


- optional count fields = © to n numberss the numeric 
part of the statistic. 


Data returned Inctude: 
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~ Status - boolean indicating whether or not the 
previous Statistic Facility request was precessed 
correctly. 

The method for assigning statistics ordinals will be 

specified in the ERS. <A separate range of numbers will 

probably be reserved for users, 

325.3 PRODUCT STATISTICS COLLECTED BY NOS/VE 

In generally the O75 is responsible for collecting job step 

statistics that can be datermined external to the products 

that is statistics that the O/S is capable of determining. 

For each product identified in SIS section 4.1 that is 

directly invoked by the users @e9e»9 via command or as a 

program initiated tasks NOS/VE will record resources used 

per invocation. Resources accounted for Includes 

- totaj] CP-time 

- maximum virtual memory used 

- maximum real memory used 

- average working set size 

~ CP<-time per memory size used 

- number of I/N requests 


= amount of data read/written to files 


Additional data to be coliected for each Invocation of a 
product include? 


- origin of job stap -—- batch commands terminal commands 
procedure Fille» executing job. 


- type of termination ~ normals product errors time 
limits Invalid memory requests operator drops etc. A 
recovered condition does not cause product termination. 


- average interactive response time for interactive 
products —- the average elapsed time between input data 
avallable and output data Issued to terminal. 
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- the fact that the product was invoked (added to count 
of the number of separate invocations). 


- number of nodules ftoaded (input units for the loader) 


~ source languages of modules toaded (added to language 
usage count). 


- disk accesses per CP second. 

These same statistics,» resource usage and additional datas 
may be collected for any user initiated job step whether 
it is a user supplied program or a COC supplied product. 
Statistics for products will be identified by product IDs 
correction level informations and task number acquired 
curing loadings 


Task number tdentifies which invocation of product x 
issued the statistic. Several asynchronous tasks may be 
executing the same product. Statistics for user written 
tasks may be Identified by primary module names task 
numbers, and other data gleaned from the file ID. 


Number of invocations wili be collected for all products 
both user called and product calied service products such 
as Access Methodss and all user taskse It could be 
collected for all modules on system !ibraries. For 
products, it represents the number of times the product 
was invoked over a given time span; for user programs it 
represents the number of times a program module written in 
janguage x was used over a given time span. The time span 
jis installation definable. 


36504 STATISTICS COLLECTED BY PRODUCTS 


In generals, oroducts are responsibie for collecting 
internal statistics that only they can know. There are 
two classes of product generated statistics - input units 
and internal usage statistics. 


3e5e4el Input Unit Statistics 


This class of statistics is concerned with the number and 
nature of user controlled data processed by the product. 
The number of input units is what PIDFR (Product Input 
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Data Failure Rate) calculations are based upon. All 
products are required to log number of input units 
precessed ger tnvacation, 


Section 3e6e2 of the AQ/R (ARH 1688) defines input units 
for various eproducts and C/S$ levels. In summary they are: 


Product Input Unit 
Language translators Ge 9» Source 

FIN» COBOL» CYBIL»s DDL lines 
Utilities such as SORT/MERGE>»s Data records 
FMUs EOMS utilities, ocy 
Services such as AMs AA» Functional 
and DMS180's Query service requests 


Input unit related statistics other than count which are 
required where applicables include: 


Language Transtators 
~ number of modules processed 
- number of declarative statements 


~ number of executable statements 


number of comment and blank lines 

- number of source statement errors for each error level 
Utilities 

- number of type n records 


n = each recognizable record type supported by the 
product 


number of records in error 
- merge order used 
~ average key size 
- average key type 


Services 
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- Number of Functions of type n 


- number of illegal/iitl-formed requests 

Many other potentially useful input related statistics are 
possiblee Products developers are encouraged to coitlect 
additional input statistics they feel are worthwhile. An 
example is source statement freaquencys i.@es number of 
each type of source statement encountered, 


35-42 Internal statistics 


This class of statistics is concerned with internal 
measures of the product as opposed to measures of the 
input data, These statistics report Internal product 
information that the O/S is not aware of. 


Exampies of such statistics are? 


- product options In effect for this execution erges 
what control statement parameters were selected. 


- internal errors encountered 


Products are required to log options used and number and 
type of internal errors encountered. The other statistics 
are highly desirable and should be collected at least on 
an optional basis. 


Many additional statistics may be applicable to specific 


productse Oevealopers are encouraged to coliect other 
statistics they feel are worthwhile. 


325.5 WHEN TO LOG STATISTICS 


The two issues of concern are: 


- when should detalled optionals statistics be 
accumulated and logged? 


- when should subordinate service products such as AA 
log statistics? 


All statistics will be controlled by installation or user 
controlied switches. The statistics Facility will provide 
the mechanisn for setting and clearing these switches» 
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Each procedure that Issues diagnostics must check the 
appropriate switch before calling the statistics 

Facility. The switches will probably exist as an array of 
bits that can be referenced but not changed by user 

tasks. The NOS/VE ERS will specify the exact form. 
Subordinate products and routines may either issue 
continuous statistics at product determined intervals or 
events or they may accumulate and report them under 
control of the host product. 


For products such as AM and AA whose statistics could be 
meaningful regardiess of the host, the first approach is 
acceptable. For examples statistics could be gathered 
from file open to file close for each file. Anyone 
interested In AA statistics for a job step would have to 
sum up the tndividual statistics on the log file. 


For subordinate products and routines such as the common 
compiler modules whose statistics are not meaningful out 
of contexts, a nechanism should be provided to enable the 
host to force out statistics on demand. That Is» the host 
must be able to inform the subordinate that its work is 
complete. [ff the subordinate actually Issues the 
statistics, the host must provide its product ID to the 
subordinates so that IP can be Included in the 

statistics. If the host actually issues the statistics 
the subordinate must return al} data and jdentifying 
informatione The first method is preferred since the host 
does not need to know which or how many statistics the 
subordinate Is collecting. 


Note that all methods of statistic reporting require 
products to recover from catastrophic external and 
Internal errors. Products must regain control so that 
they can output the accumulated statistics. Furthermores 
since O/S jogs the reason for terminations products that 
recover from abnormal external conditions must be able to 
Jet the abort happen after they issue their statistics so 
that the correct reason for the termination is recorded. 
Products that detect internal errors must be able to 
indicate that such an error happened when they aborts so 
that “internal error™ ts recorded as the reason for the 
abort. <A product may choose to terminate via an abort 
when no product error has occurred. 
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4.0 SYSTEMWIDE CONVENTIONS 


This section descrivbes the operating system and product 
set convention which must be followed by alt! standard 
software. 


The term “global” as used tn this section refers to 
constant and type definitions that are global to saveral 
products. It dees not mean “global” within a particular 
product, 


4.1 NAMES. DATES _ AND_TIMES 
Standard system naming conventions are needed for the 


following reasons: 


1. Permit recognition of the origin and maybe the purpose 
of the named entity Just by its name. 


Ze Prevent duplication of names between different 
products. 


3. Designate categorles of names that are reserved for 
COC usage so that they will not be duplicated by 
application programmers. 

These names nay be declared as entry point namess file 

names» SCU deck namesys or as names for common system 

entities such as installation options. The common system 

entity names must be declared In a form that provides a 

simple source of availability for use by any system 

implementation languages {CYBIL or assembly). 


4elel NAMING CONVENTIONS 
The system defined global names will be generated 
according to the following convention: 
PPCEXXX 
wheres 


PP -— is a 2 character alphanumeric product 
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identifier or other global identifier for the 
owner of this symbol. 


-- jdentifies the class of the name. 


~-m Ts the special character % 


XXX —— 2 or more alphanumeric characters which 


establish uniqueness within the levels of 
identification described above. The maximum 
length of this field is datermined by the other 
users of these names, Example: The loader 
determines the maximum length of an entry 
polnts the record manager the maximum tength of 
a file name, 


4ele1.1 Product Identiflecs 


AA 
AL 
AM 
AP 
AV 
BC 
cc 
C8 
C&G 
Ct 
CM 
CV 


CY 
DA 
08 
BS 
ES 
FA 
FC 
FL 
FM 
FS 
FT 
FY 
HP 
HU 
Ic 
IF 
IM 


Advanced Access Method 

Assembly Language 

Access Method 

APL 

Accounting Validation 

BASTC 

Common Compiler Modules (CCM) 
CosoL 

Common Code Generator (CCG) 
Command Language 

Configuration Management 

CYBER Automatic Vectorizing and 
Language Independent Compiler (CAVALIER) 
CYBIL 

DCN Dump Analyzer 

Interactive Debug 
Deadstart/Recovery 

Edit Screen 

File Migration Alds 

FORTRAN Compiler 

FORTRAN run time Library 

File Management Utility 

File System 

FORTRAN, Giobal to FC and FL 
CDC FORTRAN (Vectorizing) 
Hardware Performance Analyzer {HPA) 
Help Utilities 

Interstate Communication 
Interactive Facility 
Information Management Facility 


a a 
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JM Job Management 
LI LIsp 
LL Loader/\Ibrary generator 
MA Maintenance Application Language for Eaulipment 
Testing (MALET) 
ML Math Library 
MM Memory Management 
MS Maintenance Services 
NA Network Access Method 
Oc Object Code Utilities 
OF Operator Facility 
OS Operating System 
PA PASCAL (Wirth) 
PF Permanent File Management 
PM Program Management 
PS Product Set 
PR PROLOG 
Pl PL/T 
QU Query Update 
RH Remote Host Facility 
RM Resource Management 
3C Source Code Utility 
SE Set Management 
SF Statistics Facility 
SM Sort Merge 
ST Software Tools 
S¥ Shared Variabies Processor 
US User (e.ges for "user" statistics) 
vc i. C Comoiler 
Vx VX/VE - UNIX Emulator 


Selels? Other Global Identifiers 


KA Release Administrator 
This product I[dentifler is used to identify 


Installation parameters and precedures associated 
with a NOS/VE product. 


4.1.1.3 Classes.of Names 
The following list of [dentiflers naming classes is used 


for code and deck naming purposes: 


A -— Architectural and Design documentation 


se we 
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-— Design documentation (internal to CDC) 

constant 

-— declaration (decks containing types and/or 
constants) 


wow 
i 
| 


—E -— exception condition name 

F =-— file 

I -- inline text or code 

K == keypoint or keyword 

Mf =-— module 

Pp o-— procedure 

5 --— saction (static data section and/or common 
block) 

T -- type 

Vo-- variable 

X w—— XNCLItd (decks containing procedures or 


variables) 


4.1.1.% Special Charactecs 


The use of the $ sign in a name identifies the name as one 
belonging to C9C, cnc users will avoid any duplication 
with CDC names by not using the $ in any of thelr names. 


Some programming languages such as FORTRAN do not allow 
imbedded dollar sign characters in their names. CDC 
supplied procedures callable from these languages will not 
conform to the $ sign rule. 


4.1.1.5 Naming Guidelines 


RFelationshio of Code and Deck names 


The deck name must be the same as the code name whenever 
possible. In instances where it ts absolutely necessary 
to group types» constantss etce in the same deck, then it 
is allowable to use a conglomerate deck name which is 
different than the component code names. 


"Design Documentation” Deck Names (A and 8) 


Ciass A decks are for architectural and design documentation 
releasable with the code. 


Class B decks are for requirement/design documentation not 
releasable with the cade (e@eges DR—type specificationss such as 
performance) but relevent to code maintenance. 


ed 
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A "design documentation™ deck has the EXPAND attribute value of 


a 


a 


TRUE or FALSEs depending upon the needs of the product. The content? 


of this deck and all. decks *COPYed by this deck are input to the 


4 
é | 


processor named in the PROCESSOR field of the SCU deck. The PROCESS} 
is in the form of a string which represents the command by which thi. 
processor is Invoked. Documentation decks may not be processed by ai 


compiler but rather by a text formatter processore For Instances 


cgocumentation decks might be processed on the C170; then the 


PROCESSOR might be TXTCOQODE. In the futures documentation decks may 


processed on the C180 by a text processors 


Documentation decks not to be released to customers must be 


identified (by group) by the development project to Integrations 


which will ramove such decks during preparation of SMD release 
materials». 


"Compilable”™ Deck Names (M and F) 


A "compilable” deck has an EXPAND attribute value of 

TRUE. The content of this deck and all decks *COPYed by 
this deck are Input to the processor named in the 
PROCESSOR field of the SCU deck. The PROCESSOR field is 
in the form of a string which represents the command by 
which the processor is invoked. Parameters which are to 
be passed to the processors and which are meant to be 
invariant (such as optimization levels» or debug level)s 
may be included in thts stringe The order in which 
invariant parameters are specified is precisely the order 
in which they are defined for the commands even though the 
parameters are specified as equivalenced parameters. File 
references are disallowed in the processor stringe 


M class decks contain a processor defined "compilation 
unit™. Examples of such compli tation units aret MODULE to 
MODEND for CYBIL» IDENT to END for ASSEMBLE» PROGRAM to 
END for FORTRAN», etc. Module decks represent the units 
which are maintained In a Binary Module Replacement 
environment. A parent/child relationship exists between M 
and P (or V) decks which contain XREFs. To denote this 
associations the name of the parent M deck is assigned as 
a GROUP attribute of the chitd P or V deck. Thuss any 
modifications made to the child deck results in the 
ability to generate the parent deck by interrogating the 
GROUP attributes of the child deck. Likewises all decks 
which *COPY the child deck can be generated through use of 
the INCLUDE_CNPYING_DECKS Criteria File directive. The 
name associated with aM class deck is the same as that 
specified on the MODULEs IDENT» PROGRAMs etc. statements. 


se ne 


x 
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If aM deck contains code which is tater Bound into a 
Module of a different name via the BIND MODULE subcommand 
of CREOL», then the name of this Bound Module is assigned 
as a GROUP attribute of the M deck. The name of a 
corresponding F deck. which contains specific CREOL 
directives assoclated with the binding of this module is 
specified as a GROUP attribute of this M deck. 


F class decks contain source data which is retained as a 
files or contains processor directives for the processor 
named by the processor fleid.s These decks contains or 
*COPY decks containings information necessary for 
establishing program descriptionss omitting entry points 
from Bound Modules, or establishing SCL procedure 
libraries. <A typical F deck might contain COLLECT_UTEXT 
and ADD _MODULE commandsy and *COPY's to procedure decks (P 
decks) which contain the source of procedures to be added 
to a procedure Iibrarye Another use of F decks is as a 
container for directives to the Real Memory Bullder or 
Virtual Memory Linker In which segment attributes are 
defined. If a SCL procedure is to ba executed from a file 
rather than a orocedure librarys then the processor type 
of the F deck is SCL rather than CREOL. The name 
associated with F decks Is the name of this file as It Is 
accessed when the processor is invekeds or the name of the 
resultant file which is to be created. 


"Non=-compilable”™ Deck Names (C» Es Ix Ks Ps» S» Ts V) 


A "non-compitable” deck is one with the SCU deck EXPAND 
attribute value of FALSE. This type of a deck is *COPYed 
by "compl liable” decks and assumes any attributes 
associated with the *COPYing deck. 


K class decks contain KEYPOINTs KEYWORDs or statistic 
codes. These codes are defined In terms of a constant 
plus relative offsets and define a set of reiated datae 

K decks are given a conglomerate name which indicates the 
type of data being described (KEYPOINTs statistics or 
KEYWORD). 


C ctass decks contain Constants. Constants are used to 
impose an upper Jimit on rangess and provide a starting 
point from which relative offsets are computede A 
constant is global in nature by virtue of its appearance 
in a C deck, Those constants which define product 
restrictions due to their design (ege OSCSMAX_NAME_SIZE)>» 
and those constants which represent Installation options 
are the two categories of constants with packaging 
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affects. The former category of constants are named so as 
to describe the scope of effect upon other products or 
subproductse Product specific constants should be named 
using product specific two-character identifiers. The 
flatter category of constants are named with the RA product 
identifier to Indicate that the "Release Administrator™ 
assumes ownership for the value assigned to the constant. 
Since source code wil! be unavailable at many sites» the 
use of constant values must be avolded. Global constants 
should exist as one constant per decks The name of the 
deck should be the same as that of the constant being 
defined. Ownership of a constant Is assumed by the decks 
which *COPY a constant deck. Automated generation of all 
decks affected by a change to a constant deck is 
accomplished through the INCLUDE_COPYING_DECKS Criteria 
File Directive. 


T and E class decks contain Types and Exception conditions 
respectively. Since Exception conditions are typically 
described in terms of a constant plus a relative offset, 
it is acceptable for a constant deciaration to appear 
within the &— deck. E— decks are given a conglomerate name 
for the condition range. Types may be either fixed or 
adaptable. In such cases where a type is defined in terms 
of constant (such as an e@aquivalenced ordinal type) then 
the constant value may be contained in the T decke T 
decks are named the same as the primary type defined in 
the deck, If the type is a records, then the name of the 
deck Is the nane of the record defined in the deck. 


P class decks contain code procedures.» The content of 
such decks Is the source of non=-XDCL'd proceduress SCL 
procedure dafinitionss, or XREF declarations for xXDCL*d 
procedures. A SCL procedure definition will contain a 
PROC to PROCEND sequence if the P deck is used to form a 
procedure Jlibrarys otherwise the procedure will be defined 
in a F deck. Code sequences which are not bracketed by 
PROC to PROCENDs or a corresponding sequence such as 
SUBROUTINE and ENDs should be contained in I (inline code) 
class deckse 


V class decks contain variable declarationss or the XREF 
to XDCL'd variables. A chiid/parent relationship exists 
between a V deck containing an XREF and the corresponding 
Moor F deck in which the variable is XDCL'd.~ The name of 
the V deck Is the same as name of the variable which is 
defined in the deck. The name of the parent M or F deck 
is assigned as a GROUP attribute of the V deck. 
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Il class decks contain Inline code or documentations. In 
the case of codes the justification for such decks is for 
performance reasons where repeated code cannot be formed 
Into a PROCEDURE due te the expense Incurred In the 
procedure call. Otherwise, FUNCTIONS or INTRINSICS may he 
contained in I decks. Inline text is text used for code 
documentation ourposes which may also be called into a 
generated document such as an ERS. 


S class decks contain biocks of related data such as 
static data of Common Blockse An aggregate name Is 
associated with this collection of data unless the text 
data describes a specific entity. In such cases» the text 
data assumes the same descriptive string as that 
associated with the entity it is describing (eg. 
GOSSSMAINFRAME PAGEABLE_LHEAP). 


"“Non-compiljable” Deck Names (Ds X) 


Decks belonging to this category reoresent packaging 
anomalies, and should be avoided whenever possibie.e 


D class decks contain conglomerates of Types and/or 
Constants. Since it is difficult to ascribe meaningful 
identity to such combinations, the use of the D class 
should be avoided when possible. It is advantageous to 
define parameters for orocedures in aD class decke This 
anomaly exists due to the nature of the constructs 
necessary to define procedure parameters. 


X class decks contain the XDCL definition of procedures or 
variables. Tha recommended location for the source of 
XDCL'd procedures or variables is within a compilabjie deck 
(M or F class). Combining XDCL'd procedures into a single 
module is a function of the CREATE_OBJECT_LIBRARY utility 
command BINODO_MINDULE. If the XDCL'd procedure Is GATED to 
other products and/or userss then the XDCL*'d name Is 
preserved as a result of Bindings otherwise the name is 
discarded provided there is a corresponding XREF at 
binding time. Therefore, it is a product's responsibility 
to CHANGE_MODULE_LATTRIBUTES cf the Bound Module to OMIT 
names within Bound (or Unbound) modules which are not to 
be externalized by the product. It is recognized that 
teing able to combine several XDCL'd procedures and/or 
variables into a single compilation unit can provide 
additionai debug capablftities provided by a compiler. It 
is for debug purposes that X class decks exist. 
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4.1.2 RESERVED FILE NAMES 


The following Files willl have special uses: 


INPUT is that portion of the primary input file that 
follows the System command statements. 


OUTPUT is the primary output file and contains a copy of 
the job dayfile at the end when printed. 


For interactive Jabs» the terminal Is assumed to be both 
INPUT and OUTPUT. 


421.32 DATE AND TIME 


While NOS/VE provides date and time data in several 
formatss products are restricted to using one format 
unless language standards dictate otherwise. The format 
te be used Is the installation defined default format. 


For fixed position listing and file formatss date and time 
fields must be large enough to accommodate the longest 
forms returned by the 07/5. 


4.2 INTERACTIVE PROCESSING 


This section identifies capabilities products must provide 
to support users interfacing the system from interactive 
terminals. 


Products suvnport different levels of interactive usage, 
Therefore a oroduct does not necessarily support all of 
the capabilities described below. For exampies products 
that typically perform batch functions (e.g. complie 
FORTRAN source) do not provide the same tevei of 
interactive capability as one that typically performs an 
interactive function (e.g. query a file). 

Many of the capabilities are provided by the operating 
system and therefore are available to alJ terminal users 
independent of the program/application being used. 


Specific interactive capabilities to be provided by €180 
products are described below, <A key is used to indicate 
which products must inctude design and implementation of 
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the capabilities. The keys are: 


A- It is the responsibility of all products to support 
the capabliities marked with the A key» 


OQ - This key notes the terminal capabilities supported in 
the Implementation of the operating system. These are 
available with all interactive usage and are provided 
by: 


Job Management 

Message Generator 

Fhie Routing 

Basic Access Method 

Transaction Executive 
Network/Communtications Access Method 


* ¢ @ © # & 


I ~ This key notes the terminal capabilities supported by 
"interactive products”. These programs normally carry 
on a dialogue with a terminal user to obtain feedback 
and dynamically direct processinge They include? 


Job Management 
Message Generator 
Fille Routing 

HELP Utility 
Transaction Executive 
BASIC 

APL 

OS Utilittes 
Query/Update 

Report Writer 

FMU 

Interactive Debuggers 
SORT/MERGE 

SCcuU 

Editors 

Conversion Utilities 


Ce ee) 


4.2.1 INTERACTIVE OUTPUT 
4e2e1e1 General 


a) The page width and length at an output device varies 
not only by device types but also by the size of paper 
being used In the device. The user must be able to 
indicate the operational page width and page length of 
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the outout device. Defaults that correspond te the 
terminal characteristics are supported. 
-O<- 


b) Lines of data that exceed the output device page width 
must be delivered without loss of data. Data that 
would be output beyond the right side of the page must 
be foided onto a second or successive tine (reference 
section 32434125). 
= Qj 


c) The user must be able to have every output line 
formatted so as not to exceed the output device page 
width provided the output device page width ts not 
jess than 72 characters. As a minimums the user must 
be able to specify that output be formatted for page 
widths of 72 or 132 print positions (reference 
section 3e22ele4)>s 
~j=— 


d) Any outeut that may go te an ASCII sequential file may 
instead go to a terminal. 
-=- 


e) Any output may contain a carriage control character 
(reference section 3,313). 


f) The carriage control character will direct printing of 
an output File and will not appear in the print output. 
=G= 


4.2e1.-2 Messages 


a) Messages must be courteouse Words such as “"ijllegal®™ 
should he avoided In favor of words tike "incorrect" 
or "unknown", Error messages musts where appropriates 
suggest what the user ought to do to correct the error. 
-~A@ 


b) Messages must be formatted for narrow listings.e 
-\- 

c) Messages must be meaningful such that an Inexpertienced 
or casual user [is able to understand the message and 
respond appropriately without reference to a manual. 
Ao 
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d) 


e) 


f) 
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Any message longer than 290 characters must have an 
aiternate brief counterpart. 
-A- 


A user must be able to select elther a brief or long 
form of a message» When using the brief form of 
messages the user should be able to request that the 
last message be repeated in its long form. 

oa © Doel 


Messages soliciting input (prompts) should always be 
used to indicate that the user is expected to supply 
input. 

oJ 


Prompts should appear on the same line as the input 
whenever physically possible. 
-[- 


4,2e123 Listiogs 


a) 


b) 


c) 


d) 


Pages of output that are longer than the output device 
page length must be delivered without loss of data. 
Data that exceeds the page length must be continued 
onto a second or successive page. 

-o— 


Pages of output must not be delivered to a 
non-hardcopy output device so fast as to overwrite any 
previous output before the user can read it if a wait 
option has been selected by the terminal user. 

-~j-~ 


The user should be able to have heading information 
repeated on the second and successive terminal pages 
of a tistings when display space is limited and the 
information band width is tows the user might choose 
to not use space to dispiay repetitive headings and be 
able to see more data» Where the listing consists of 
many columns that are hard to differentiates, the user 
might choose to have headings repeated on every pages 
This capability requires that: 1) Page Header text be 
identified so it can be discardeds and 2) Title text 
be identified so it can be replicated, 

=l[= 


When initiating a function the user must be able to 
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select alternate amounts of detail to be included in 
the listing. By selecting tess details, the user ought 
to be able to have more Items displayed on each pages 
and not just get tess information per page» 

= A 


4.2.2 INTERACTIVE INPUT 


These standards supplement section 2423. 


4e2eZ2el General 


a) 


b) 


c) 


d) 


é) 


f) 


9) 


User discovered typing errors must be correctable by 
backspacing and retyping. 
-G= 


The user must be able to cancel the Input tine being 
typed at any point before input completion is 
indicated. 


No extraneous blanks will be appended to the end of 
the user defined input data for padding. Application 
of this rule Is only required If allowed within a 
product's standard, 

= A = 


No user typed trailing blanks will be deleted from the 
Input data. The application of this rule is only 
required if allowed within a product's standards. 


Any input that may come from an ASCII sequential file 
may Instead be supplied by a terminal connected as 
that file. 

-A= 


A single Input may consist of more than one tine. A 
prompt may allow multiple tines of input in responses 
An input collection mode may be implemented In this 
manner. 

= 

Operations requiring only a few parameters should not 
require more than a single input. The user may enter 
all parameters for a directive or ail directives for a 
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h) 


i) 


single system level command as a single input In order 


to reduce the number of interactions and the time to 
complete the directive or command. 


The user must be able to use the standard 
abbreviations for command namess directives and 
parameter Identiflers in order to reduce typing. 
=~ Am 


After Input of a command or directive has been 
completed» incomplete input should not be treated as 
an errors but should cause further prompting for the 
missing DParameterse 

~[-~- 


4.2222 Input Diagnoses 


a) 


b) 


c) 


d) 


$2223 CONTROL 


Errors in input will be diagnosed immediately 
following the offending Input ilne. 
-[=- 


Diagnosed input errors must be correctable without 
“exiting” the dialogue with the program. 
om Tw 


Wwhera possible allow diagnosed input errors to be 
corrected without re-entering the entire line. 
-{[- 


Any input diagnosed to the terminal must be 
correctable by terminal input immediately following 
the diagnostic whether or not the original input was 
from the terminal (see 462e63e1)-¢ After receiving the 
corrected input from the terminal input will revert to 
the primary source. 

~-~[- 
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“e2e30el Connectivity 


a) The user must be able to havea his terminal connected 
as an ASCII sequentiai input file and an ASCII 
sequential output file for any program. 
~ A 


b) The user must be able to suppress the verification 
listing of Input when the input source and the output 
destination are both the terminal. 

-A- 


c) Products that allow input directives from a file other 
than INPUT must allow the user to have Input 
directives fron a source other than the terminal 
Jisted for verificetion at the terminal. 

-A- 


d) Products that allow input directives from a file other 
than INPUT must allow the user to have input 
directives From a source other than the terminal 
diagnosed to the terminal. 
~A- 


e) The user should be abie toe fogically disconnect the 
terminal from an executing program without causing the 
program to be suspended. The program should continue 
execution and the user should be able to 
simultaneously enter other commands cetera? 
execution of other programs). 
an (jo 


42.3.2 Interruets.and Connection Breaks 


a) The user nust have a method for gaining control over a 
program In execution. This is known as an Interrupt. 


b) An Interruoted program will not be aborted as a result 
of the interrupt. 
-(0- 


c) For a program written to execute in an interactive 
environments an interrupt must cause the program to 
enter a known state. This state will normally be one 
that solicits directives or commands from the terminal. 
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d) For a program written to execute in a batch 
environments an interrupt must cause the program to be 
suspended in such a manner as to be restartable during 
the same terminal session. Control is returned to the 
command language interpreters 
-O= 


@) <A connection break is often caused by a communication 
line fallure. <A connection break must not cause the 
terminal sassion to be aborteds but must cause it to 
be suspended In such a manner as to be restartable 
when the terminal user can again get connected, 

-~j-=- 


f) A user must be able to restart a suspended program. 
-G- 


g) <A user must be able to terminate a suspended program 
without first restarting it. 
-j= 


h) A program written to execute in an interactive 
environment must accept a termination directive in the 
state entered as a result of en interrupt. This 
directive mnust he the same as the corresponding system 
command to terminate a suspended program. 
~[- 


i) <Any iIncomptete terminal input request from a program 
that is suspended should be reissued (with the proper 
prompt) when the program is restarted. 

-[- 


J) The terminal user must be able to interrupt the output 
being delivered to the terminal and cause the 
remainder of the output to not be delivered to the 
terminal until thea next prompt. 

-= 


4o2e3e3 Status 


a) The terminal user must be able to solicit a report to 
determine the process of a programs without causing a 
change in the state of the program. 


4-17 
CYBER it0 System Interface Standard 
ape ets 


SYSTEMWIDE CONVENTIONS 


b) Progress reports must indicate the functional progress 
of the programe. For example: 


"compiling program SAMs." 
"compiling subroutine TOMee.™ 


“"preoaring global cross-references..." 


c) The terminal user must be able to solicit a report to 
determine the system environment within which a 
program is running without causing a change in the 
state of the program. An installation option to 
disabie this must be provided. 

-O— 


gd) The system environment report must indicate {possibly 
indirectly) the response time the terminal user can 
expect to experience. This might be by indicating the 
fength of swap-out queuess the number of interactive 
userss etce An Instailation option to disable this 
must be provided. 
-(=- 


e) The terminal user must be able to solicit a report of 
the state of Its program without causing a change in 
the progran'ts statee An installation option to 
disable this must be provided. 

-O— 


f) The program state report must indicate the rate at 
which the user's program is progressing relative to 
real times and the Impediment to progress. For 
example: 

"014223313 = 2.54 CP seconds Swapped Out" 
7014324340 —- 5.72 CP seconds Running” 
72142273190 - 6.21 CP seconds Finished” 
Possibie states should recognize the points of delay 
in the system; these might be Pagings Swap-outs 
Waiting for terminal inputs etc. 
== 


9) The terminal user must be able to define terminal 
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attributes to be associated with an interactive 

session (@egGe» backspace characters echo modes screen 
size). The terminal user must be able to display the 
terminal attributes currently in effect for a terminal. 


a) The terminal user should always be able to get a 
reasonable response to the input HELP. The response 
should identify the userts alternatives and possible 
correct Jnout. As a directives, HELP should Indicate 
what directives are abie to be used at that point. 
The user should be abie to proceed after the response 
to a HELP input as if the Interaction had never taken 
place, 

-J— 


4e2e% PRODUCT SET RUN TIME COMMANDS 


4eo20%.1 PAUSE _ and STO2 Literal 


PAUSE n Cin FORTRAN) and STOP literal (in COBOL) are very 
similar. They should be processed in the same way. 


ae The message PAUSE text will be displayed on the 
operator's terminal or console.» Text is n or Jliterat,s 
and is a maximum size of 58 characters. For batch 
jobs, the operator is the primary system operatore An 
OFPSSEND TO OPERATOR with an OPERATOR ID of "SYSTEM 
OPERATOR*' is executed to send the message. For 
Interactive Jobss an AMPSPUT NEXT request referencing 
the file DUTPUT Is executed to send the messagee This 
wiil result In a message on the terminal. 


be. In batchs an OFPSPECEIVE FROM OPERATOR with the WAIT 
parameter and the same id as above js executed to 
suspend the Job and wait for the typein from the 
system operator. The operator will respond with a 
REPLY ACTION command. In interactive modes an 
AMPSGET NEXT request on the file INPUT is executed 
(this may not be legals another connected file may 
have to be used). In either cases the data is thrown 
away and the job Is continued. 
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4e2e04e2 ACCEPT FROM CONSOLE 


The ACCEPT FROM CONSOLE (in COBOL) should be processed In 
exactly the same way as STOP literal (46264:1). Text 
would be the data from a previously executed DISPLAY UPON 
CONSOLE WITH NQ ADVANCING or the message 'ENTER COBOL 
INPUT VIA REPLY ACTION?! If there was no DISPLAY. 
Interaction Is with the system operator only. (If 
messages sent via OFPSSEND TQ GPERATOR aliso appeared on 
the terminals It could cause confusion for the terminal 
operator,) 


403 INSTALLATION PagaMETees 


NOS/VE will permit modification of all system parameters 
dynamically during system execution. The term 
"installation parameter", as used in the classical tCpdc 
senses is not valid for NOS/VE. 


System parameters fall into the following general 
categories: 


° Hardware characteristics (eeges # Of CPU's, type of 


CPU) 

* System and product defaults (e.ge» defauit tape 
density) 

e Accounting parameters 

* Limits parameters (@ege,» maximum FL) 


e Timing parameters 


System parameter defaults can be set at the following 
times: 


* Comolte time (compllation at CDC) 
* Bulild time (deadstart tape build at user site) 
* Deadstart time (vla operator type-in) 


These parameters may be tested dynamically and action 
taken accordingly. The product set will require no 


4-26 
CYBER 180 System Interface Standard 
B4/07/27 
4.0 SYSTEMWIDE CONVENTIONS 
423 INSTALLATION PARAMETERS 


perameter specifiations and will dynamically test system 
parameters during execution via requests to NOS/VE. 


The following table Indicates the permitted range of 
system parameter contrel for the product set and operating 
system. An X indicates that the option is alloweds and a 
blank entry indicates that the option is not allowed. Any 
exception must have the explicit approval of ADE&C,. 


be me a ee ae no ee ae se a ese $e meee a a a ee ee ee a a eee + 
! Time of Set ! Set Times 11 Use Times 1 
1 ANd YSR ben nn nnn} emer me ec Ce 
1 Type of ’ Comp. ! Bulld 1 D/S 1! Exece $1 D/S 3! Exece ? 
3 Parameter 1 Time ! Time ! Time ? Time 22 Time ? Time $3 
$e eee a ee ee $ we ef ee $e ee ee +o-———— oo $m eee + 
{ Product Set : ! 3 42 ! 3 
! Hardware $ } : : $3 : x 3 
i Defaults : ; 4 : e ! : 
1 Accounting 1 1 1 3 1 i j 
1 Limits H 3 ] iB : X ! 
3 Tuning : ’ : H '! i : 
H ! } ! 1 a] ! 1 
1 O98 ! } } } 1] 3 | 
} Hardware : X 4 X ' xX 3} X :) x. X | 
H Defaults ! x 3 X , xX 3 xX de x 3 x } 
1 Accounting 1 x l X } xX x 1} xX 43 X | 
! Limits ! x : X H Xx 1 X 3 xX 3 X 1 
’ Tuning ? x { x ! xX } x +4 xX !} x | 
heediostentanteaienteatatentenheententenantontanteatenteen fe ef ee ee ee fe ee Son eatetetenietons thom $e ee nee + 


4o3.1 GENERAL GUIDELINES 


As a general rules the number of system parameters should 
be kept to an absolute minimum. This will minimize the 
additional testing imposed by these options and will 
reduce the number of "different" versions in the fleid. 


A firm requirement on both the operating system and the 
product set Is that no racompiflation at a user site will 
ever be required to instail the software. This is a 
requirement of binary release. 
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4.3.2 LIST OF PRODUCT SET PARAMETERS 


The following system parameters may be tested dynamically 
by the product set via requests to NOS/VE (Cinctuding 
networking): 


type of CPU 

BS name and version 

line width or screen width 

terminal type 

screen langth or page ltength 
. print lines Jimit 

4o% ERQOR PROCESSING 


* @ © #6 


The purpose of this section is to describe the conventions 
and responsibilities of processing different error 
conditions, 


44.1 STATUS VARIABLE 


All command and procedure interfaces to the system that 
are visible to the end user must have a status varlabie as 
a parameter. The status variable is used to convey the 
result of the command or procedure ands In case of error, 
provide information explaining what went wronge 


For commandss the status parameter should always be 
optional. When it is quoted by a users the assumption Is 
that the variable will be tested subsequentiy in the 
command stream and some appropriate action taken. 
Therefores the conditions returned to the user should onty 
convey information the user fs likely to understand. 


Fer procedures» the status parameter is requirede Again 
the conditions returned should be as understandable to the 
user as possible. This is particularly important when 
there are multiple procedure calis made within our 
software as the result of a single cali by a user 
procedure. Emphasis should be piaced on improving the 
status returned to the user rather than blindly passing 
back obscure status from the depths of the system. 


Detailed formats of the status variable are available in 
the NOS/VE ERS. 
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424.2 ERROR TERMINATION 


There are a number of errors that can occur in a product» 
some of which can be detected and some of which can't. 
This section deals with the processing to be performed 
when detectable errors occure 


First of alls the product should try to detect as many 
errors as gracefully as possible. This means that 
internal software tests should be used to detect errors as 
well as using the condition handiing facilities of the 
operating system to receive control in the event of a 
system or hardware detected error. The product cannot 
simply rety on the standard operating system abort 
processing. 

When an error is datecteds the product should provide as 
much of the following error localization information as 
possible. ‘Some of the Information will not be applicable 
to all products. 


* Type of error termination (standard system messages 
should be used for this message). 


® Full traceback of the call sequence to the procedure 
containing the error. This will be by procedure name 
and line number or reiative address depending upon the 
amount of traceback/debug information released with 
the product. 


e Information regarding the user data being processed. 
For a compilers this might be the procedure name and 
fine number currently belng processed, For a utility 
or data management product, it might be the current 
record. 


* Optional dumps of useful internal tables. 


The above information should only be fogged for error 
terminations that are probably caused by product failure. 
It should not be logged for conditions such as time iimit 
or operator drop which are clearly not product errors. 
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424.3 INTERACTIVE ERROR PROCESSING 


This section supplements section 422, “Interactive 
Processing”. 


In considering this topic it is necessary to distinguish 
between error nessages and diagnostics. These terms are 
difficult to define orecisely but are Intuitively distinct 
nonetheless. An error message is generally a summary of a 
command; in an Interactive environment it wants to be 
displayed at the terminal so the user can find out what 
happened, Diagnostics are generaily a part of a larger 
whole (Ceeges Listable output) which due to their volume 
only want to be selaectiveiy displayed. 

An example is a compiler which provides a single error 
message telling how many errors occurred during 
compifiation and produces a diagnostic for each compilation 
errors 


4.4.3.1 Erroc Messages 


ae All error nessages should be issued via the standard 
message generator. The message generator will 
determine whether the message should go to the 
terminal or the ftoaqs etc. 


b. Messages must be courteous. People tend to react in a 
more emotional fashion when using a computer 
Interactively than when using it in a batch mode. 
Words such as "illegai™ should be avoided in favor of 
words like “Incorrect™ or “"unknown™,. Error messages 
should explain to the users what they did wrong ands 
if possible, how to correct it. 


ce Messages must be meaningful such that an Inexpertenced 
or casual user is able to understand the messages and 
respond appropriately without reference to a manual. 


ds» Any message longer than twenty characters must have an 
alternate brief counterpart. The user must be abife to 
select either the brief or the long form of the 
messages 
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4.4.3.2 Diagnestics 


a) Points b and cy» above aiso apply to diagnostics. 
Diagnostics should explain the problem from the user's 
perspective rather than the program's, For example? 


"Comma missing after third parameter" 
instead of 
MQOVPPARSEPR detected illegal syntax". 


b) While diagnostics are not typically displayed at a 
terminal by defaults they are looked at by interactive 
users. This must be considered when defining the 
location of the diagnostics in the listings 
identifying the diagnostics with a mark that Is 
uniquely detectable with a text editors etc. 


4.4.3.3 Ineput._ Diagnosis 


This section anppites to all input that can reasonably be 
expected to come from a terminal (@egex command utility 
subcommands). 


a» Errors in input will be diagnosed immediately 
following the incorrect input. 


b. Diagnosed input errors must be correctable without 
exiting the dialogue with the program. 


Ce Diagnosed input @rrors may be corrected without 
reentering the entire line. 


de Any Input diagnosed to the terminal must be 
correctable by terminal input immediately following 
the diagnostic whether or not the original input was 
from the terminal. 


4o4e4 BATCH ERROR PROCESSTNG 
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4e4e4e.1 Error Messages 


Batch error messages should follow exactly the same 
guidelines as interactive particularity the usage of the 
message generator. 


4.4.4.2 Ineut Diagnosis 


The kind of user interaction that is desirable in 
interactive mode Is of course Inappropriate In batch 

mode, Emphasis should ba placed on detecting as many real 
errors as possibie even after a fatal error has occurred. 
The key word here is "reai"™; producing a large number of 
extraneous ®rror messages or diagnostics will uitimately 
jead to people only correcting one probiem at a time. 


424.5 TRANSACTION ERRAR PROCESSING 
This section wll! be added when more design on the 
transaction facility has occurred. 


42426 RESTART 


This section will be added when more design on the system 
restart capabilities has occurred. 


45 EFFECTIVE _USE_OF_C182_ HARDWARE 


425.1 HARDWARE OPERATION 


This section describes software conventions which must be 
followed for the hardware to function in a predictable 
mannere 
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4.5.1.1 Interlock Words 


Convention: Locate all interlock words in cache bypass 
segments. 


Special system Instructions are provided in the CPU and 
the IBU to interlock multiple processors/I0U. In generals» 
these function by exchanging the contents of a register 
and a word in memory. Fotlowing this exchange the 
register may ba Investigated te determine whether the lock 
has been set. For examples a zero word in memory can be 
selected to mean "no flock™, then by exchanging a non-zero 
register the lock will have been set if a zero value is 
returned. It Is imperative that such Interlock words be 
unique. To guarantee this they are placed in cache bypass 
segments. Notice that the Instructions which are designed 
to test and set flocks automaticaliy bypass cache. 

Problems arise when the interlock words are accessed by 
ether Instructions such as loads. 


4e5e1l.e2 Pre~serialization_of Clear Lock 


Convention: Before clearing a single bit tock (via a Store 
8it Instruction) first set the lock by a Test 
and Set 8it Instruction. 

Care must be taken whenever an interlock word Is set or 

cleared to pre-serialize the operatione This is done to 

ensure thats In the event that memory references are being 
satisfied out of sequences all outstanding memory 
references are completed before changing the tock. In 
practices CYBER 180 systems designed to date always 
satisfy memory references in sequencee Howevers this may 

not always be the caSee The Instruction which sets a 

single bit lock (Test and Set Bit) performs the necessary 

pre-serialization. Howevers to clear the lock a Store Bit 

(with a zero operand) must be used. Since this 

instruction has a general utility it does not 

pre-serialize. To compensates the Test and Set Bit 

instruction poste-serializes. Hences to ensure a 

pre=serlalization of the clear locks the tock should first 

be set (with a Test and Set Bit instruction)» then cleared 
by the next Instruction. 
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4e5.1.3 Register Reservations 


Convention: Registers ADmA4 and X0-X1 shali be reserved 
for special functions. 


The CYBER 189 Instructions make use of certain registers 
to hold given values.s The assignments are as foilows: 


AO - Dynamic Space Pointer (DSP) 
Current Stack Frame Pointer (CSF) 
Previous Save Area Pointer (PFA) 
Binding Section Pointer (BSP) 
Argumant List Pointer (ALP) 


> bP } 
ne 


These registers hold those values by software conventions 
but a convention which is supported by the hardware. 

Hences it Is vary lmoortant that they be supported by all 
software procedures. In particulars, Al and A2 must never 
be altered by instructions other than Calls Return and Pop. 


In addition to the reservations aboves registers XO and X1 
have a special meaning in the hardware. For many 
instructions» the XG designator is used to indicate no 
register. Hences register XG cannot be used by these 
instructions. Both X09 ang Xl are used as fixed utility 
registers for several instructionse Examples are? 


1) Load/Store multiple and CALL instructions use X90 
for aosave area descriptor. 

2) All conpare instructions return a value to 
Xl-Rights as does the Mark to Boolean instruction. 


3) The BDP Instructions optionally use XO-Right and 
X1—-Right to hold operand lengths. 


Since these registers are used for special purposess care 
must be exercised if they are used In a general manner. 
4e5e1e4% Alignmenot_of Tables.and_Wards 
Convention: Align certain tabies and words on specified 
houndariese 
Although CYBER 180 is nominally a byte addressable 


machines real nemory is organized into 64-bit words. 
Consequentlys the performance of certain operations has 
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been optimized by placing the ecperands on word 

boundaries.s The complete set of data alignments necessary 
is given belows along with a brief description of why the 
alignment Is required and what witl happen when the data 
is not aligned correctly. 


4e5ele4e1 64-BIT WORD BOUNDARIES 


The follewing data either must bes, or should be aligned on 
word boundaries: 


1) Process Segment Table - For performance reasons the 
hardware Indexes Into the 
segment table at a word 
boundary. The virtual memory 
address translation mechanism 
will fail if the segment 
table Is incorrectiy aligned. 


2) Binding Sections ~ To maximize the reach into 
the Binding Section by the 
Cati Indirect instructions 
access is made to a word 
boundary. If the Binding 
Section Is Incorrectly 
aligned, then an Address 
Specification Error results 
when a Call Indirect is 
issued. 

3) Procedure Entry Points = To maximize the reach of the 
Call Relative instructions, a 
branch is made to a word 
boundary. Since the 
instruction forces the 
address to a word address» 
results will be unpredictable 
if the procedure target was 
not correctly aligned. Note 
that even though it is not 
strictly necessary for 
procedures called via a 
Binding Section to be word 
aligned, difficuities could 
still result if they are 
not. This Is because the 
CYBER 180 Library Generators 
in the process of “binding"™ 
may convert Call Indirect 
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instructions to Call Relative 
instructions. 


4) Debug tist Entries - To simolify the hardwares and 
to optimize performance when 
in debug modes the hardware 
accesses debug ilst entries 
on word boundariese 
Incorrect alignment will 
cause unpredictable results. 


5) Interlock Words ~ Interlock words used In 
conjunction with the 
Compare/Swap operation must 
be aligned on a word 
boundarye This is necessary 
for the processor to satisfy 
the non-preemptive 
requirements of the 
instruction. Processors 
utilize the 64-bit memory 
exchange function in this 
cperation., That function 
operates on a real memory 
word. Incorrect alignment 
will yield an Address 
Specification Error. 


6) Stack Frames ~ By software convention ontys 
stack frames should be 
aligned con word boundarles. 
This enables the hardware to 
foad and store the registers 
held in the save area from 
data on word boundaries. 
Incorrect alignment will not 
cause any problems since the 
hardware always adjusts 
(forces) the Dynamic Space 
Pointer to a word boundary 
before accessing a stack 


frame. 
7) Central Memory Date - The IOU can only reference 
Accessed by tha IDU central memory wordse Hence, 


it would require some special 
code in PPP's to decode data 
not stored on word 
boundaries. This is really a 
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pragmatic software convention 
since a PP has no way to 
specify a central memory 
address other than on a word 
boundary.» 


405012422 QTHER BOUNDARTES 


The following data must be aligned on boundaries other 
than 64-bit word or B-bit byte, 


(1) Exchange Packages = 128—bit (2 word) Boundaries 


To optimize the performance of the exchange jump on some 
processors, the hardware addresses two words at one time. 
Results will be unpredictable if the exchange package is 
incorrectly aligned. 


(2) Instructions ~- Parcel (2-byte) Boundarles 


Instructionss which are either 16-bit or 32-bit 
quantitiess must be aligned on parcel boundaries. 
Failures to do this will either result in unpredictabie 
behaviors or an Address Speciflecation will be detected. 


{3) Page Table —- Page Tabie Length Boundary 

To minimize the time needed to translate addresses from 
virtual to real» the hardware catenates {rather than adds) 
the Page Table Addresses (PTA) to the page table index. 
For the catenation to yield the correct address, the 
low-order bits of the PTAs as determined by the page table 
lengths must be zero. Failure to structure the PTA In 
this manner wlll cause the address transiate mechanism to 
fail. 


445.2 HARDWARE PERFORMANCE 


Whereas the previous section dealt with conventions 
necessary to make the hardware work correctliys, this 
section deats with conventions necessary to make the 
hardware work efficiently. As such they are not 
mandatorys and in some cases represent merely suggestions 
as to how to optimize certain functions. 
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4e5e2e1 Locality.of Reference 


Convention: Place all code and all data to be used at one 
time in one places and keep to a minimum the number of 
segments required to execute a given task. 


The CYBER 186 virtual memory organization provides the 
basis for the system security and simplifies the explicit 
organization of a program into overlays. Howevers all 
programmers have responsibilities if system throughput is 
to be optimized. A prime responsibility Is to maintain a 
strict ftocality of reference. That is collect all code 
and all data that Is to be used at one time into 
contiguous pages in one segment (each for code and data). 
This has two advantagess it minimizes the working set (the 
number of pages allocated in real memory at any given 
point of time)», and it also minimizes the number of 
entries which nust be made in the buffer memories. By 
minimizing the working set the number of concurrent tasks 
which can be held In real memory is naximized. Thiss in 
turny maximizes system throughput. 


Optimizing around the huffer memories represent a slightly 
different problem. These have a finite size and contain 
the most recently us2d Segment Descriptor Entries and Page 
Table Entries, If a large number of segments are in use 
at one times or if a large number of pages are in use at 
ene timey then the buffer memories will be unable to hold 
all the necessary entries and they will be constantly 
joading new values. The affect wil} be similar to not 
having them at al! and performance will degrade 
considerably. 

Consequentivs not only should programmers maintain a 
locality of references but they should also try to 
localize the number of segments used by a given task. 


4o5e2e2 Register _Allocatlon_and Usage 


Convention: Allocate A-Registers and X-Registers from the 
smali numbers on upe 


As a result of the special functions for which AO-A4 and 
XO—-X1 are useds and the method of saving/restoring 
contiguous ragisters by the CALL/RETURN instructions, 
register usage should always start with the smallest 
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possible number (typically A5 and X2)5. This wili help to 
minimize the number of registers which must be saved 
across procedure calls. Thiss in turns will optimize 
performance in this area. 


4.523 SECURITY 


This section lists software conventions needed to provide 
a secure environment at all times. Since a major 
objective of the CYBER 180 program is to provide a highly 
secure systems these conventions become mandatory. These 
conventions are closely related to those in Section 2. 
Just as they are required to make the hardware operate in 
a corrects predictabite manners so are these required to 
guarantee that the security and protection algorithms 
function correctly. 


%o5e3.1 Procedure Sarameters 


Convention: 1) Always use caller's argument list pointers 
for accessing caller'ts data. 


2) Always jioad pointer parameters directly 
Into AmRegisters ~ via Load A Instructions. 


3) Whenever possibile avoid moving record 
structures that contain pointers. 


4) Avoid passing pointers between rings 
either wave 


5) Avoid data structures containing direct 
pointers that cross rings either waye 


These conventions are mandatory for those procedure calls 
from one procedure to a second one with more privilege. 
When a procedure is called by another procedures, it 
executes on behalf of the caller. It is the 
responsibility of the callee to ensure that it does not 
execute with more privilege than caller. The hardware 
provides the basic security mechanisms. In this cases it 
ensures that callee Is called from within Its call ring 
brackets», and that it Is called via a Binding Section. It 
may then access code and data belonging to or accessible 
by caller. This code and data is referenced via pointers 
held in A-Registers»s and the hardware performs a ring 
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number vote whenever an A-Register Is loaded. This 
mechanism ensures the lteast privilege (highest ring 
number) is always accorded the user. However, there are 
many ways this mechanism can be be=passed.e. The simplest 
method is for callee to load a pointer into an X-Register» 
then copy it to an A-Register. If caiter places a low 
ring number (zero would do) in the pointers then it will 
end up with calleets ring number in the AmRegister. That 
is it will end up with more privilege than that to which 
caller is entitled. It is callee's responsibility to 
ensure this does not happene The onus for maintaining 
security always falls on the more privileged procedure. 
Hences the convention. 


4e6 SUPPORI_OF_ERBCOIC DATA 


ERCDIC data can he divided Into two distinct classes? 


le 411 B8—bit character data (aiso known as coded datas 
including unpacked numeric data types)3 and 


2 jIntermixed character and non-character data. 


Support for the former (ali character) Is provided by the 
operating system. IF ERCDIC is specified on the request 
card» the tanve driver automatically transiates to ASCII 
when reading the tape and transiates back to EBCDIC when 
writing the tape. 


Support for the flatter (intermixed character and 
non=character)», and for the EBCDIC collating sequences 
varies by product: 


Cc P F S F @ D 

0 L 0 / M R M 

B / R M U M S$ 

0 I T 1 

L R 8 

A 0 

EBCDTC SUPPORT N 

Intermixed E8C0IC inout file @ x 
Intermixed F8CITC output file e x 
EBCDIC collating sequence X X x 
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X = support reguired at R1 of product 
e = eventual support desirable 


Support of intermixed input and output files means use of 
the special ©1890 Instructions to process the following 
"transiated”" non-character EBCDIC data types: 


° Binary {signed and unsigned) 


° Packed Decimal {siagned and unsigned) 
4.7 KEYPOINT_USAGE 


The CY189 keypoint facility provides a mechanism to enable 
collection of statistics for performance monitoringe A 
data reduction software package is available to summarize 
these statistics based on descriptors contained In a 
keypoint descriptor file (KDF). This section documents 
the conventions to be followed by the operating system and 
product set in the usage of this facility. 


4.721 KEYPGINT CLASSES 


Five keypoint classes named ENTRY» EXITs UNUSUAL» DEBUG» 
and DATA are dafined for the operating system and product 
sete 


ENTRY Every gated procedure plus all major 
internal procedures (those shared across 
functional areas) should contain a 
keypoint of this classe These keypoints 
should be placed as close as possibie to 
the entry to the procedure, 


EXIT Every gated procedure plus all major 
Internal procedures (those shared across 
functional areas) should contain a 
keypoitnt of this class» These keypoints 
should be placed as close as possibte to 
the exit from the procedure. 


UNUSUAL Every situation which is unexpected or 
quite unusual should contain a keypoint of 
this classe It is Intended that these 
keypoints would be enabled at ali times. 
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The Frequency of encountering these 
keypoints should be very low. The DATA 
keypoltnt class Is not allowed In 
conjunction with a keypoint of class 
unusuale 


DEBUG These keypoints would be for providing 
additlonai trace information as an assist 
in debugging of hardware or software 
problems. DE8UG class keypoints would be 
most useful In the more complex areas of 
the system. The primary use of keypoints 
In HCS and NOS/VE up to this point has 
been for debugging purposess 


DATA This kKeypolnt class can be used with the 
ENTRY» EXITs and DEBUG keypoints for the 
gathering of extra data. All DATA 
keypofnts encountered are supplying 
additional data which will be associated 
with the Jast ENTRY,» EXIT or DEBUG 
keypoint. Hences they should follow as ; 
closely as possible after the ENTRY» EXIT» 
or DEBUG keypoint; in particulars there 
should he no intervening CALL 
Instruction. DATA keypoints should be 
used with care since the PMF hardware can 
only buffer up 16 keypoints; keypoint 
clustering can cause lost keypoints. 


Keypotint Data and Identifications 


Upon successful execution each keypoint instruction will 
provide a total of 32 bits of information. The convention 
uses 12 bits of this for keypoint identification and the 
remaining 20 bits as user supplied datae Try to use this 
20 bits to provide meaningful information (taskids segment 
numbers fileids queue tengths page numbers times etce). 

On DATA class keypoints the data belongs to the previous 
keypoint and the full 32 bits is avallable for additional 
user data. 


4e7elel Qperating Syster 


The keypoint classes for NOS/VE are as follows? 


OSCSDATA=0 
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OSCSUNUSUAL®1 
OSCSENTRY=2 
OSCSEXIT=3 
OSCSDEBUG=4. 


Keypoint class 53 Is reserved for NOS/VE. 
4e7ele2 Product Set 


The keypoint classes for the product set are as follows? 


PSCEDATA=6 
PSCSUNUSUAL #7? 
PSCSENTRY=8 
PSCSEXIT=9 
PSCSDEBUG=19 


4o7e1.3 Qther Classes 
The keypoint classes 11-14 are reserved for users. 
Keypoint class 1° Is reserved for PMF hardware control. 
42722 KEYPOINT IDENTIFIERS 
A maximum of 4995 keypoint identifiers are available for 
f{each) NOS/VE and the product set. The combination of 
keypoint class and identifier is unique within the system. 


%e7e2el Operating Systen 


(To be supplied) 


4.72202 Product Set 


The set of 4995 available identifiers is partitioned into 
a primary range table and an overflow range table.» Every 
product set menber has an entry in the primary table; the 
range size is 50. Those product set members which require 
more than 50 will be assigned one or more entries in the 
overflow tables which also has a range size of 50. 


The primary range table is given below? 


CY3FR 16890 System Interface Standard 
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Product Identifier 


AA 
AP 
BC 
CB 
DB 
FC 
FL 
EM 
FT 


IM 


PA 
Pi 
QU 


3M 


$cu 


Advanced Access Method 


APL 


COBOL 

Interactive Debug 
FORTRAN Compiler 
Fortran Run-Time 

File Management Utility 
FORTRAN Giobal 


Information Management 
Facility 


PASCAL 

PL/I 

Query Update 

Sort/Merge 

Shared Variables Processor 
Common Compiler Modules 
Common Code Generator 
Host Compiler 

Math Library 

CYRIL 

Source Cade Utility 
Assembier 


File Migration Aids 


Primary range 


0 
50 


49 

99 
149 
199 
249 
299 
349 
399 
449 


499 


549 
559 
649 
699 
749 
799 
849 
899 
949 
999 
1649 
1099 
1149 


on we 
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LI LISP 1150 - 1199 
AD Ada 1200 - 1249 
FV Coc Fortran 1250 = 1299 
VX VX/VE 1300 - 1349 
vc C compiler 1350 - 1399 
{Reserved for future 1400 - 1999 
oproducts) 


The overflow range extends from 2000 to 4095. 


Assignment Is based on an as-needed basis in groups of 
502 A given product may have more than one assignment 
jn the overflow range. 


4e753 KEYPGINT USE 


From a software point of views keypoints are special 
commands that are inserted in a module according to the 
guidelines specified In section 4.7.1. For a module 
written In CY®IL» the #KEYPOGINT Intrinsic can be used to 
generate the kaypoint instruction (refer to CYBIL Language 
Specifications ARH229%», and MIGDS»s ARH1L700» for detaiis). 


The main entry keypoitnt identifying a product set mamber 
should include data which indicates the actual version of 
the product. This is useful for tracking simultaneous 
execution of the same or different versions of a product. 


se oe ee 


ne ob 
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This standard its to be followed by the object code 
generated by the compliers and by any assembler code 
written as part of standard software, 


In addition to these standardss assembler code 
(handwritten or compiler generated) will conform to the 
coding standards described in CYBER 180 MAINTENANCE 
SOFTWARE CODING CONVENTIONS (DAP ARH2160). 


9e1 USE_DE_LOADER_EEATURES 


1. The loader specification is limited to that written in 
its formal documentation. Programmers shall not 
depend on additional characteristics determined by 
empirical observations as such behavior may be subject 
to change. Examples which have caused trouble on 
CY170 are the presetting of undefined variabless the 
order cof loading from a iilbrarys and the address at 
which the First code is iocaded. 


22 Runtime routines shali not limit the program 
structures of thelr userse On CY176 all CRM ] 
routines must be in the root segment of a segmented 
loads and CMM must have at teast one routine In the 
main overitay of an overlaid program. Such 
restrictions must be avoided on CY180,. 


3. The following table shows in which sections particular 
types of data should be alflocateds and the attributes 
the section should have. 


Attributes R = reads W = writes 8 = Binding and 
—E = execute. 


Section 
Data Type Type Att Comment and Examples 
"Static" Working RaW Ai variables not 


allocated on the stacks In 
common or explicitiy 
allocated to a section. 
Includes FORTRAN local 
variables, CYBIL CSTATIC] 
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and (XDCLI] variables. 


Constants(1) Working R All Jiteral constants 
which for reason of 
indirect addressing or 
length cannot be expressed 
directly In the code. 


Constants(2) Code E Optionallys constants as 
in (1) which are less than 
8 bytes long and 
conveniently accessed 
through the LBYTP 
instruction. Note that 
the "constant™ may not be 
a PVAs 


'XREF” Binding 8B Data deciared in another 
unit of compilation are 
usually referenced through 
pointers placed in the 
binding section by the 
foader (rather than in 
user sections Indirectly 
referenced through the 
binding sections where 
they would be inaccessibie 
to the binder). 


Heaps common 

extens- 

Ibfe PywW For the system heap see 
section 5424e32 Other 
heaps are deciared in 
CYBIL. 


4. The following action should be taken if a compiler 
detects a fatal error in the source code it is 
compilings unless tha compiler was callfed with 
*"DEBUG20C" (see section 2.2)3 
An IDR record shalt be issued containing the string 

*“arrors in compilation" 


in the comment fleld. The non-executable attribute 
Shall be sete 


If DEBUG=0C was selected, the compiler shall continue 
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normal processing as far as possible, 


Se All comoilers shoutd emit loader names (common block 
namesy XREF namess module names» etc.) using upper 
case alphabetic letters when letters occur In the 
names, An exception to this rule is made for any 
language which requires the distinction between upper 
and jlower case names» 


3o2 INTERLANGUAGE CALLING _ SEQUENCES 


Purpose 


The purpose of the interlanguage caliing sequence is to 
facilitate Inter-language procedure calis. This is 
particularly desirable on CYBER 18C because of the system 
level support for sharing of code between executing 
tasks. For examples It would be desirable to have onty 
ene set of mathematical routines to be used by all 
janguagese 


Restrictions 


All CYBER 135 Compilers must be capable of generating the 
CYBER 180 Interlanguage Calling Sequence for an externally 
referenceable code moduTe. it is a goal in the definition 
ef this calling sequence that It be useable by the 
majority of the compilers as a subset of their standard 
calling sequence. It obviously cannot meet ali of the 
needs of Tanguages as diverse as BASIC and PL/I. It would 
be acceptable (but certainiy not preferabie) if a 
particular Janguage were to require special declarations 
or attributes on a procedure call to cause the generation 
of this calling sequence, 


It is expected that users in the various programming 
languages may have to take additional steps with respect 
to data declarations to guarantee that the alJgnment and 
packing correspond to that specified by this interchange 
standard. The user Is also responsiblie for the values 
passed via this calling sequence. For examples a Boolean 
variable might contain vaiues O-7 (since it occupies a 
byte) but the common calling sequence only assures 
intertanguage sapability for the values 6 and 1. 

In generals a compiler may employ any cailing sequence it 
chooses between Itself and its library or non-external 
procedures. Exceptions to this will be for routines which 
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can be of general use to many tanguages (@eges math 
library routines). Such routines may have a fast calling 
sequence but must also provide an entry point conforming 
to the interlanguage calling sequence. 


Se2@el CALLING SEQUENCE FORMATS 


Seeelel 


The interlanguage calling sequence is defined to include not only 
the layout of the parameter tists but also the layout of any 
descriptors associated with parameters in the list. Two formats for 
the Inter language calling sequence are avallable,. The term 
"jnterlanguage calling sequence” is used to refer to these two 
formats collectively. Two different formats are required in order 
to provide flexibility of usage from language to Janguage while not 
unreasonably degrading performance and usability. These two formats 
wili be referred to as the "System®” and "Generali" formats. 
Extensions to either of these formats may be made via a DAP against 
the SIS. 


The calling sequance provided by a compiler for use between internal 
procedures and functions known to be written in the same language 
need not conform to elther format of the Interlanguage caliing 
sequence, Additionally there is no requirement to use the 
interlanguage calling sequence between compiler generated procedures 
and functions and any assembler procedures and functions provided in 
aoruntime library specific to that language. In generals assembler 
procedures and functions are responsible for accepting a parameter 
list format of the kind generated by their potential callers. 
However calis to the scaiar CMML call-by-refereance procedures and 
functions must conform to the system formats while calls to the 
vector/array CMML calluby_ reference procedures and functions must 
conform to tha General formate 


Kinds_of Parameters 


For purposes of expositions three kinds of parameters will be 
distinguished: value parameterss simp{fe reference parameters, and 
extended reference parameterss 


Value parameters are those parameters for which a value is intended 
to be passed, The calling program can assume that the actual 
argument it passes will not be changed by the called program. Note 
that this does not imply a specific implementation technique 
(several are voossible). ~ cf gf 
tA beta E & 


Reference parameters are those parameters for which an object is 
intended to be passed, The calling program must assume that the 


t 
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Se2ele3 


5-5 
R 160 System Interface Standard 
84/67/27 
COMPILER AND ASSEMBLY CODE CONVENTIONS 
1.1 Kinds of Parameters 


actual argument it passes may he changed by the calfed program. 
Note that this does not imply a specific implementation techniques 
although at teast an address must normally be passede Some 
reference parameters also require that certain descriptor 
information must be passed along with the address, 


Simpie reference parameters are those reference parameters which 
require only an address» or only an address pilus aie string 
descriptors to be passed to the caliing routine. 


Extended reference parameters are those reference parameters which 
are composed of an address plus a string descriptor pilus a 
non-string descriptors or of an address plus a none-string 
descriptor. 


System Eormat_of_the_Lnterlanguage Calling Sequence 


This format Is the one used by the system implementation tanguage 
(CYBIL)» and all operating system interfaces. This format is 
documented in detall In section 5.2.5.1 of the SIS. 


General.Eormat_of_ the Inteclanguage Calling Sequence 


This format is more general than the system formate It wild be used 
by CDC FORTRAN. This format is documented in detail in section 
S42 ebee of the SiS 


Summacy_of Eormat Differences 


The primary difference between the System and Generali formats is in 
the placement and content of descriptorse System format and General 
format actual parameter lists are identical if only simple reference 
Parameters are passed, AI! System format descriptors are placed 
directly in the oaraneter List following the PVA of the object being 
describeds, while General format non-string descriptors are placed 
outside the paraneter list. The General format parameter tist 
contains the PVA of the descriptor as well as the PVA of the object 
being described. 


General format value parameters have the same form as System format 
value parameters except when the vaiue parameter is less than one 
word in size or is a pointer to procedures The General format 
requires that the value parameter be right aligned with sign fill on 
the teft for Integers and subranges of Integers and zero fill 
otherwise, while the System format requires right alignment but does 
not define the fIlil blts on the teft. 
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Use of the General format of the Interlanguage calling sequence 
requires that a “big” (i.e. longer than a word) value parameter 
which Is passed via a pointer will have been copled by the caller. 
The passed pointer Is a pointer to the copys, and the called program 
is free to write into the memory pointed to. The System format dees 
not specify whether or not a “big” value parameter will have been 


copied by the callers so In this case the called program should not 


write into the mamory pointed toe 


Calis _Potentiaitly from Another Language 


Any procedure or function which is Intended to be callabie from an 
external module potentially written in another Janguage should 
accept for that calf one (or a subset of cone) of the two formats of 
the Intertanguage calling sequence. Each compiler must document 
which of the two sequence formats It accepts, or state that none of 
its procedures and functions are externally callable from another 
language. 


Language Interilanguage Format Accepted 
ADA “-not interlanguage callable- 
BASIC “not interlanguage callable- 
¢ “to be determined= 
COBOL System format 
CYSIL System format 
FORTRAN General format 
PASCAL not interlanguage callable- 


Cails_Potentially._to.Anotherc_Language 


A compiler may assume that no call it generates is an interlanguage 
call uniess the author of the source program has explicitly 
Indicated that a particular calli is interlanguagee This means that 
each tanguage which supports calls to modules written in another 
language must provide a mechanism within the source tanguage with 
which the author of the source program can expficitity indicate that 
a@ particular call is interlanguage. This mechanism must be 
formulated such that the author is further required to state 
explicitly (by name) which other language is being called. It is 
then up to the compsier te generate the correct interlanguage 
calling sequence for the call. Thus the compiier must know which 
languages accept which calling sequences. It remains the 
responsibility of the authors not the compilers to ensure that the 
actual and formal parameters of the cali are compatible. The 
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compiler has the responsibliity to generate the correct layout 


the parameter list and parameter descriptorss as expected by the 


called language. 


These provisions do not require a compiler or Janguage to provide 


inter fanguage calls» but they do define restrictions on 


interlanguage calling is to be supported. A language may support 
Interlanguage calls to only a limited number of other languages, If 
it so choosese Note that even if a language supports direct 
interlanguage callsy it is not required to also support indirect 


interlanguage calls via dereferenced pointers-to-procedure. 


De2eleHel SUPPORT FOR CALLS TO ANOTHER LANGUAGE 


If a language supports calis to modules written In another languages 
and that other language accepts calls with simpie reference 
parameters, then the calling language musts at the minimums support 
calis with simple reference parameters. A string descriptor must be 


supplied for any object which takes ones untess the author of 


caliing program has explicitiy Indicated that no string descriptor 
need be passed. An exnolicit indication is possible in languages» 
such as CYBIl» which allow the reference parameter in an external 


procedure declaration to be specified as either fixed 


(descriptor need not be passed) or adaptable type (descriptor must 


be passed). 


The calling language is strongly encouraged to also provide support 
for calis with value parameters and extended reference parameters 
the called language accepts such calls. This support would consist 
of a mechanism within the source language to explicitiy indicates 


for each actual parameter of the Interlanguage cail» whether 
parameter is to be passed by values» by simplie references or 


extended reference, The compller then has the responsibility to 


generate the appropriate calling sequence. 


5Dete2 CALL 


The procedura call instruction CALLSEGs, Reference #115 as 
defined in the CYS8ER 180 MIGDS will be used to perform the 
procedure call. 


203 REGISTER SAVING CONVENTIONS 


For generalized axternaj calls and calls to formal 
procedures, the compiler may not assume that the called 
procedure wil! save and restore registers. <Any registers 
to be saved must be- Saved on the stack using the save 


o€ 4 e/ ye ‘ul et P 6 ae as ‘yn fy Hitt LU rn CA t. Cc 
om CS sy itacgee! 
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mechanism of the CALL Instruction. 

Internai calls need not use the CALLSEGs Reference #115 
instruction. They may use CALLREL Reference #116 or any 
other code sequence which meets their needs. For Internal 
calls the compilers have the option whether to save 
registers or not. Internal calls Include calls to; 

a) the compiler'ts own library routines» 


Db) nested procedures within the same compilation unit» 
Se2e3e1 Information _feaquiced Across Call 

The following Information may be required in making a call. 

Some of the Information is net always required ~- See footnotes. 

Dynamic to Caller and Callee 

* basic stack control registers (A0» Aly AZ) *** 

* parameter list pointer (A4)*** 

. static chain/disolay* 

* binding section pointer (A3) *** 

° product defined information 

Dynamic to Callee,y Static to Caller 

. fine number of call (see traceback section) *** 

* Number of parameters(X0»s bits 32-47) *** 

° descriptor area Indicator 

° descriptor area pointer (if any) 

Static to Caller and Callee 

° name of callee (see traceback section) 

* size of display/nesting depth*s ** 


° frame size/language** 


on ao 46 
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* type of Frame} @e9-6 Procs funcs, co-proc** 


* Block structured languages only. 
** Traceback mode only. 
**k* Required on calls made with the Interlanguage calling sequence. 


50204 FUNCTIONS 


A function Is a procedure that returns a value. The 
function value is in the registers or in memory depending 
on the type of value being returned. Since function 
references are usually part of another expression that is 
being evaluateds It is generally desirable to have the 
value returned in a register. 


If the function value is a pointers then the value is 
returned as a PVA in AF. A procedure calling a 
pointer-valued function must not save register AF on the 
call. A pointer-valued function may have the ring number 
Fieid of AF altered by the RETURN instruction if it is 
called across a ring boundary. 


If the function value is a scalar of Known length fess 
than or equal to 54 bits in tengths it is returned right 
aligned in XF. <A procedure calling such a function must 
not save register XF on the call. 


If the function value is double precision or complex then 
the vajue is raturned In registers XE and XF. xXF holds 

the least significant 64 bits of the valuee <A procedure 
calling such a function must not save XE or XF on the call. 


If the function value is non=-scaltar then it is stored at 
the address defined by the first element of the parameter 
list. The secand element of the parameter ‘fist specifies 
the first actual parameter. 

A scalar function result is defined as follows: 


° CYBIL - characters bocleans integers, ordinals» 
subrangess celi» pointer. 


° FORTRAN - logical, integers real» doubie precision, 
complexy FORTRAN boolean. * 


* COBOL = compos, comp-l»s comp-2s boolean. 


° PL/I - Integer{FIXED REAL)» real(FLOAT REAL)» 


oes a be 
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compo lex (COMPLEX) 
* BASIC - real 
® PASCAL - ee onte {enumerated types, sub-range)>» 
real 


Scalar function values are returned right aligned in the 
result register. Fill (if any) is zero bits. Note that 8 
byte numeric Items raquire no fill. 


* FORTRAN boolean corresponds to a Full CYBER 180 word without 


type. It is not the same as the boolean type mentioned 
elsewhere In this section. 


5 PARAMETER LIST 


The parameter Vist Is allocated on a word boundary In memory. 
entry in the parameter list must also begin on a word boundary. 


entry to the callees, ragister A& will point to the parameter Iist. 
i parameters 
ued “functions). 
If the procedure being called is a function whose vaiue Is to be 
returned in menorys the first element of the parameter tist defines 
the Jlocation at which the value is to be stored. If no parameters 


Rits 32-47 of register <xXQ will contain the number 
(including the pseudo parameter for none<-scalar 


(nor psa@udo parameters) area to be passeds then the contents of 


are undefined and <X9 must specify zero parameters. Under certain 
circumstances detailed below, a flag word must immediately precede 


the first word of the voarameter fist. 


Se2e%el System Eormat_Parameter_List 


{This is currently documented in the CYBIL Handbooks, DCS# ARH3078, 


sections 7.1 and 8.2. The following addition must be made to 
documentation in order to conform to the SIS.] 


For any potentially interlanguage call In which a System format 
actual parameter list Is passed that contains only simple reference 
Oarameters: The parameter list must be immedlately preceded by a 
flag word whose value is the 64-bit integer zero. The string 
descriptor must be Included for any object which takes ones untess 


the author of the source program has explicitiy indicated that 


need not be ovassed. These restrictions are made to insure 
compatibility between the release 1e1.22 product set calling 
conventions and those for aii future raleasese A flag word need not 


precede any other System format actual parameter lists. 


sa we 
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3e205e2 Genecal_Cormat_ Pacametec List 


The General format parameter Jist must always be preceded by a flag 
‘words The parameter list itself is composed of two parts. The 
first pert has exactly one word for each parameter (including the 
ee OA : ; 
pseudo parameter for non=scalar valued functions). If the fiag word 
preceding the parameter list Is zero then only this first part is 
presents otherwise the second (extension) part must also be present. 
This parameter list extension follows immediately after the first 
part of the parameter tJlists, and has exactiy the same length In 
words. There is a one-to-one correspondence between word j of the 
First part and word j of the extension. 


The parameter fist extension is required if and only if one or more 
of the actual parameters is an extended reference parameter or is a 
pointer-to-procedure value parameter with a static link, 


5 e205 e201 FLAG WORD PRECEDING PARAMETER LIST 


The flag word immediately preceding a General format actual 
parameter list must be present for any potentially interlanguage 
call. This flag word has the following internal structure: 


record : 
F1lz DOF FFFFFPFFFFFC1G)» 
F232 Oe,9F F(16)>5 
F332 O..0FF(16)>» 

recend 


Fietd f1 must always be set to integer zero» It is reserved for 
future uses. Field F2 has a language dependent values, but may be 
Nonzero only Uf field f3 %Is nonzero. Fleid f3 must be set to 
integer zero If the parameter jiist extension is absent, and must be 
set to integer one otherwise. Any tlanguage accepting calls 
according to the General format must accept interlanguage calls for 
which field 2 Is Zero. An tinterlianguage caller wiil never be 
reguired to sat Fleld f2 to a non=zero value. If field f2 is set to 
aonon-zero value for an Interlanguage calls it is the responsibility 
of the caller to set the field according to the expectations of the 
callee,. 


Be 205 e2e2 GENERAL FORMAT VALUE PARAMETERS 


If a value paraneter is greater than one word in length and is not a 
pointer-to-procedures then it is passed using an identical format to 
that for a reference parameter. 


\ 
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If a value paramater is a pointer-to-procedure then the first part 
of that parameter list entry must contain the left justified PVA of 
the Code Base Pointer of the procedure in the binding section. The 
second part of the entry (when an extension is required) must 
contain the left justifled PVA of the static fink or must contain 
the NIt pointer if there is no static Ilinke The 16 bits to the 
right of each of these PVAs is unused and undefined. This can be 
diagrammed as? 


dp a a nen ee a 1 se ae wes a + oe ae oe ooo’ 
3; PVA (Code Base) ; Gadee: H static link/ NIL } undefi 
ae ian o $e ee ew ee ee ee ee ee fee ee ao ome 


If a vaitue parameter is less than or equal to a word in ftengths then 
a copy of the value parameter is placed directly in the first part 
of the parameter JTist right aligned In a words with sign fill on the 
teft for integers and subranges of integers and zero fila otherwise. 
The associated word In the second part (when an extension is 
required) is unused and undefined. Note that if a PVA having no 
associated descriptor Is passed by values then by this rule the PVA 
is placed directiy In the parameter lists right aligned in a words 
with the word zero-filled on the left. This can be diagrammed as: 


Sp ee ee a nn a se ne a a ew ee ee so 
3 value {right Justified) H H undefined ; 
ee a ae a es ee ee ne a ae a ee + $e ee ee eee eee eee + 


2050203 GENERAL FORMAT STMPLE REFERENCE PARAMETERS 


Simple reference parameters are passed either as a PVA or as a PVA 
plus string descriptor. Parameters consisting solely of a PVA are 
placed directly In the first part of the parameter list entry left 
aligned in a word; with the rightmost 16 bits of the word unused and 
undefined. The value of the word In the associated second part (If 
an extension Is required) must be the 64=—bit integer zero. This can 
be diagrammed as: 


fe ee ee en ee fp me a wn ss cas me + fon meee a eee a ae ot en ae oe a + 
+ PVA (object) +; undef} ; C ; 
a ee a ee ee aoe mp wee aan mn ee oe se + $e ee ee a non a a eeteetenteted + 


Simple reference parameters consisting solely of a PVA ptus a string 
descriptor are placed directly in the first part of the parameter 
list entry with the PVA left aligned In a words, followed immediately 
by the two byte tong string descriptor. The value of the word iin 
the associated second oart (if an extension Is required) must be the 
64-bit integer zero. This can be diagrammed as? 
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Se2eFe20% GENERAL FORMAT EXTENDED REFERENCE PARAMETERS 


Extended reference parameters require that the nen-string descriptor 


be 


of the size of that descriptor. 
the parameter list must have been set to onee The first p 
parameter list entry will contain the PVA of the object r 


left 


aligned. If the reference 


passed indirect!iy using the parameter list extensions 


regardless 


Field f3 of the fiag word preceding 


= 


includes a string descr 


that descriptor Is placed in the 16 bits immediately foll 
are unused and undefi 


PVA» 


parameter 


otherwise those 16 bits 


list extension for this entry will contain the 


lecation (which must be on a word boundary) in memory 
descriptor is located. The PVA in the parameter list ext 


feft 


undefined. 


Sete te 205 GENERAL FORMAT STRING 


A string 


art of the 
eferenced, 
iptor then 
Owing the 
ned. The 
PVA of a 
where the 
ension is 


aligned In a word with the rightmost 16 bits being unused and 


$e ee a Ses 
3 PVA (object) | ; undef: 


fp oe are sa ee se se nn ss ON Se ee pe wee + 
H ue (ob Ject) sHengths 
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DESCRIPTORS 


This can be diagrammed as one of: 


pee ae see 0 ee ee cae a ee se ee 
: PVA (denerintar) 
> 0 Oils ip in 5 Ge ee OE a Oe tm ae ne cm ste 
ah ee eee ee ce ae tee ee som te ee eee me ce ee ee 


descriptor is a l6—bit unsigned integer 


indicating the fength of a string In bytes. When pres 
placed in the primary portion of 
following (and in the same word as) the PVA of the object being 
described. <A string descriptor 
parameters to objects of type 
strings substrings or array over 

Ssubrange of characters strings or substringe The string 
for an array Indicates the ftength In bytes of a single element. 


a 


5020502206 GENERAL FORMAT APRAY DESCRIPTORS 


The 


description given below. 
elements 


the parameter fist jf 


is required for ali! 
characters, subrange of 
component type of 


layout of an array descriptor must adhere to the ps 
Note that “extent” refers to the number of 
in a particular dimensions 


“stride” refers to the 


—peee—-e + 
H undef! 
—ptemee—e + 
a + 
H inde? 
$e —em ewe + 


(0.265535) 
ents it Is 
mmediately 


reference 
character» 


character» 
descriptor 


eudo-C YBIL 


distance 
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(measured In terms of array elements) between two consecutive 
elements of the same dimensions and "rank" refers to the number of 
dimensions jin the array. Array descriptors must be aligned on a 
word boundary. 


array descriptor = array [1 2» rank] of record 
extent: Integers 
strides: integers» 
lower bound: integers 

recend; 


For languages such as CYPIL and FORTRAN 77» arrays are represented 
and stored as contiguous oabjects; stride is a function solely of the 
extents. However the Introduction of array sections in CDC FORTRAN 
necessitates that an explicit stride be passed in the parameter list 
since sections need not be contiguous In memory; they may have a 
non-unity increment in each dimension of the arrays which must be 
Included in the calculation of the stride. The stride vaiue for 
multi-dimens ional arrays is cajiculated differently depending upon 
whether arravs are steered coiumnwise or rowwise. For one 
djmensional arrays the formulas are equivaient. Note that one 
dimensional contiguous arrays have a stride of one. 


For arrays which are stored columnwise in memory (1.28. with the 
leftmost subscrist varying fastest) the following formula is used: 


; H 
stride(}l) = Jnerti) * $ ; Ej) 
| 
3 4 
jz9 


where stride(l) is the stride in the i-th dimensions incr(i) is the 
increment of the I-th dimensions and E(0) is defined to be one. For 
contiguous arrays», E(j) is the extent of the j-th dimension. For 
array sectionss E(JjJ) is the extent of the j-th dimension of the 
contiguous array of which this is a section. For example if we have 
the FORTRAN declaration: 

DIMENSION 2(155390) 
then for Cc we haye incr(1)=1» incr(2)=1>» extent(1) 215» 
extent(2)230, E(1)#15, E(2)=305 stride(1)=#l» and stride(2)«15. For 
the sections 

C(1210%225 1222233) 
we have? iner(1)22»5 iner(2)=3y extent{(1)#5» extent(2)*4, E(1)#15, 
E(2)8309 stride{1l)s22*1=225 and stride (2)=3*14*15=45, 
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For arrays which are stored rowwlse in memory (1.¢e. with the 
rightmost subscript varying fastest) the following formula is used? 


3 3 
9 e 
stride(i) = Inerli) * 3 § €(€ 49) 
jJzi¢i 


where stridell) is the stride in the i-th dimensions incr (i) is the 
increment of the i-th dimensions r is the rank of the arrays and 
F{r+1l) is defined te be one, For contiguous arrayss E(J) Is the 
extent of the j-th dimension. For array sections, E{j) is the 
extent of tha j-th dimension of the contiguous array of which this 
is a section» For example if we have the FORTRAN declaration: 
ROWWISE R(15530) 
then for R we havet rds $tiner(l)=ls Iner(2)=1l, extent{1)=15,s 
extent(2)=30» E(1)=15s E(2)=30»9 stride{(1)=30»5 and stride{2)=1. For 
the secticn: 
R(12:1022, 1232233) 
we have? r=2,) %$iner{1l)=2s incr({2)=39 extent(1)=5, extent(2)=4) 
E(1)=15» €{2)=30» stride(1)=2%*1%*36=60» and stride{(2)=3%*123. 


52206 DATA REPRESENTATION 


The Following subsections define the representations of 
data which must be used if an item of a particular type is 
to be passed between languagese Languages may have types 
beyond these but data of those types cannot be passed to 
other languagese A language is not forced to provide for 
all of the following data tyres. 


5e2e6e1 Integer 


An integer may occupy 1 to 8 bytes of storagee For 
languages with size allocations dependent on the subrange 
of integers specifieds, the amount of storage allocated 
must be the minimum number of bits needed to hold the 
specified range rounded up to the next full byte. 
Subranges that include negative numbers must use the 
leftmost bit of the fleld as the sign bit. Negative 
values are represented as negative two's complement 
quantities. Subranges of only positive numbers will not 
provide a sign bit. The range of signed integers Is 
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—2*#*63 << | € 2**63—1. The range of unsigned Integers is © 
< i < 2** 63-1. 


Several languages have an enumerated type called 
ordinals. These are mapped onto the non-negative 
integers. Allocation rules are the same as for unsigned 
Integers. Uf ordinals are passed to a fanguage without 
ordinais they nust be treated as Integer values and 
vice-versa, 


Jwo sizes of integers correspond to easily manipulated 
hardware formats and are identified as separate subtypes 
of integer to provide for tanguages with only options for 
half or full word signed integer values. 


De2eGalel 4 BYTE INTEGER 


A half integer will be represented by a 4 byte (32 bit) 
quantity in the CYBER 189 integer format i.@es a signed 
two's complement 32—bit quantitys, in which the leftmost 
bit is the sign bit. The range of 4 byte Integers Is 
-2**31 € ji € 2**21-1. 


5e2e6e1-2 8 BYTE INTEGER 


A full integer will be represented by an 8 byte (654 bit) 
quantity in the CYBER 189 integer format i+@e, a signed 
two's compiement 64-bit quantity, in which the leftmost 
bit is the sign bit. The range of 8 byte integers Is 
-~2%**63 <¢ | ¢ 2**63=1, 


5e2e6e2 Eixed Length Charactec (String) 


Fixed length character data will be stored as a sequence 
of consecutive 8 bit bytes. The character set will be 
ASCII. 


Real data will be represented by an 8 byte (64 bit) 


quantity in th2 CYBER single precision floating point 
format. Ail reali data will be normalized. 


ae ae ee am 


ae we #86 we 


we we we 


5-17 
CYR8ER 180 System Interface Standard 
84/67/27 
5.0 COMPILER AND ASSEMBLY CODE CONVENTIONS 
522623 Real 


5220504 Louble Precision 


Double precision data will be represented by a 16 byte 
(128 bit) quantity in the CYBER 180 double precision 
floating point format. It must be normalized. The PVA in 
the parameter list polnts to the first byte of the double 
precision datum. Thea second (lower precision half) is 
jocated at PVA+8 bytes. The sign and exponent fields of 
the lower part are considered to be correct at any given 
time, Input and constant assignment routines are 
responsible for insuring corrct signs and exponents upon 
initial construction of the number. DOouble precision 
operations wil! maintain this format. 


5.206535 Comeolex 


Complex data will occupy 16 bytes (128 bits) in memory and 
will consist of two realss where the first real represents 
the “"real™ part and the second real represents the 
“jmaginary™ part of the complex quantity. The PVA In the 
parameter list points to the first byte of the complex 
datum (the real part). The imaginary part is located at 
PVA+8 bytes. 


Deleheo BOQIean 


Boolean data occuples a single byte, A value of one 
indicates true and a value of zero indicates false. 


5e2e6e7 Pointer 


A pointer is a PVA. It occupies six bytes. Pointers may 
identify data of any of the other data types. The nil 
pointer is defined as a PVA with a ring field value of *F" 
hexadecimals, segment field value “"FFF™ hexadecimal, and 
address field value "200C0000" hexadecimal. 


5e2e7 DATA ALIGNMENT AND PACKING 
The purpose of the common cailing sequence is to provide 


the ability to pass data between diverse languagese The 
interlanguage call Is assumed to represent a small 
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percentage of all calds and generally be used by 
knowledgeable users, Therefore, for performance in the 
word orfented languages (FORTRAN, in particular) a 
least-common-denominator alignment of word is used. 


Data types which require 8 bytes to store are required to 
be word aligned to improve performancee This permits the 
use of the load/store word Instructions which are faster 
than load/store of 8 bytes. The space penalty for word 
aligning simple varlables is felt te be small especially 
since it costs a maximum of 7 bytes per orocedure if ail 
the word aligned items are stored contiguously. 


5e2eTel Variables 


Variables may be of any of the above data types. The 
alignment of a particular type must be as follows? 


Data Type Alignment 
1-7 Byte Integer Byte 
8 Byte Integer Word 
Character(String) Byte 
Real Word 
Double PreclIsion word 
Complex Word 
Boolean Byte 
Pointer Byte 


S5e2e7e2 Structuces 


Structures must begin word aligned, 


Alignment of data to be passed between languages In 
structures must be as follows: 


Data Type Alignment 
1-7 Byte Integer Byte 
B Byte Integer Word 
Character(String) Byte 
Real Word 
Double Precision Word 
Complex Word 
Boolean Byte 


Pointer Byte 
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If a byte aligned item is followed by a word aligned items 
up to seven bytes may be skipped (and left unused) to 
regain word alignment. If a byte item follows a byte 
item, they may be in consecutive bytes». 


Se2e7e3 Artays 


5 ote? e301 ARRAYS OF VARTABLES 


The arrays represent a collection of data items of one 
uniform type. Arrays must be word aligned if the data 
type they contain is word aligned. Uniess required by an 
external standard allo languages should store arrays with 
the rightmost subscript varying fastest. FORTRANs for 
examples is constrained by ANSI standards to store arrays 
with the leftmost subscript varying fastest. If a user 
passes a multidimensional array between languages with 
different storage orders,y it is the user's responsibillty 
to handle this. Arrays must be byte aligned if all of the 
constituent elements are byte aligned. The parameter tist 
PVA identifies the first element of the arraye Subsequent 
elements must be contiguous and in ascending storage 
address sequence. 


Se2eTete2 ARRAYS OF STRUCTURES 
If any element of the structure is required to be word 
aligneds each array element must start on a word boundary, 
Re2eTede3 COMMON BLOCKS 
Items within common blocks must be aligned consistently to 
achieve interlanguage communication. Common blocks will 


begin word aligned. Alignment of data within the common 
block will be the same as for structures. 


5 e208 LANGUAGE INTERCHANGE TABLE 


The following table shows the possible parameter types 
that may be used between languages. If a tetter appears 
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at an intersection in the table, that type may be passed. 


Types are encoded as follows: 


J = 1—35 5-7 Byte Integer 0 = ordinal 

H = 4 Byte Integer I = 8 Byte Integer 

C = Character (string) R = Real 

D * Double Precision Z = Complex 

8 = Boolean P = Pointer 

A = Array S$ = Structure 

All = all types of the language 

Calfee 

CYBIL PASCAL(W) FORTRAN COBOL PL/I BASIC 
Caller 
CYBIL All HITJCBPSAQR ICARD HICBSARD HICBPSAR CR 
PASCAL(W) HIJCS8PSA0R ALL Ica HICBSA HICBPSA Cc 
FORTRAN ICARD Ica All ICRDA ICRDZA CRA 
CABAL HICBSARD HICRSA ICRDA All HICSRDSA CRA 
PL/T HICBPSAR HICRPSA ICRDZA HICBRDSA All CRA 
BASIC CR c | CRA CRA CRA All 

Notes: 


1) PL/I may not have a double orecision data type due to 
possible high overhead in supporting the maximum 
precision rules. This will be determined later. 

2) If arrays are permitted between two languagesys the 
type of the array is restricted to the types of 
variables that are permitted between the two Janguages. 

3) Arrays of characters in BASIC cannot be passed to 
other languages» and vice versae 


Se2ehel Extended Ioterchange 


The language Interchange table defines the parameter types 
that can be usad between pairs of languagese In many 
cases restrictions exist because a particular ltanguage 


6 woe ae 
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flecks a data type. For example, BASIC lacks integer type 
since it stores them as reals. In many Instances the type 
mismatches could be mapped by interface code between the 
procedure calls, The foliowing mechanism Is proposed to 
support such mapping when and if it becomes a requirement. 


In order to nao parameters» an intercept routine must gain 
control from the callers map things and pass control to 
the calliee, The reverse may be necessary upon returne 
The user should not have to be aware of the activities of 
the interface routine or invoke it directly. To achieve 
thiss the loader must have a mechanism for detecting the 
need for an Interface routine and inserting same in the 
cali/return paths. The insertion mechanism can be similar 
to the one used for Analyze Program Dynamics (APD). 
Detection of the need for inserting the interface routine 
can be done with load time argument checking mechanisms» 


For each pair of languages {X and Y) where interface 
mapping is desireds toader tables defining relevant 
infermation about actual and formal parameters must be 
cefined. <A routine (activated during loading by the 
joader If a call from X toe Y Is found) will compare the 
actual and formal parameter lists to determine if mapping 
is required. I? nots the loader simply links as usual. 
Otherwises aX to Y mapping routine from a library is 
inserted into the linkage by the toader,. 


The X to Y mapping routine receives the actual and formai 
parameter list information from the loader, 


The caller Information Is obtained by giving the P address 
of caller to a toader service routine which returns a PVA 
if the actual parameter list information for the current 
cali. The callee information Is obtained by giving the 
code base pointer of callee to a loader service routines 


The mapping routine uses this information to transform the 
parameter list and/or data representations before calling 
the callee. When the caliee returnsy the mapper wild 
receive contro! to do any mapping on return parameters. 


5209 REGISTER CALL FUNCTIONS 


In many languages there exist commoniy used sets of 
functions (for examplas mathematical functions) for which 
it is more effictent (though less general) to pass a 
fimited set of parameter values via registerse Up to 
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elght (64 bit values) can be passed In registers X2 — X9. 
The first parameter value would be in X2» the second in 
X3y etce If a double word value (says doubie precision) 
is reaquireds it uses two consecutive registers. The 
specific register used for a routine may be inferred from 
the type of the parameter. For examples SQRT{(X) will use 
X2 while DSORT(D) will use X2 and X3. These rules apply 
te the fallowing data types as parameters? 


1-7 byte integers 
8 byte integers 
Real 

Double Preciston 
Comp jex 


Return registers for register cali functions (see 3.2.3) 
must not be saved in calling them. 


No rules are svacified for characters boolean or pointer 
data pending identification of functions using these 
argument types that are of general utility. 


The register cal} entry point is not bound by the 
conventions of the common calling sequence, 


All register call functions intended for general use must 
also offer an entry point that accepts the common calling 
sequence (8.2 above) and referenceable by a CALLSEG 
instruction. 


5e3 INTERPRODUCT FILE_uUSAsce 


Interproduct flie sharing between executing subsystems 
will be addressed. It wiil specify under what conditions 
a product will be able to perform I/0 on a file dectared 
by another product. It will also address closing and 
flushing of flles at Job step termination when 
interlanguage files are being used. 


304 STORAGE MANAGEMENT 


Purpose 


In order that user object code from different compilers 
can co-exist In one job step while using a timited number 
of segmentss certain conventions must be observeds 
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Each user wilt] have a limited number of segments. This 
means that object code from different compilers must be 
able to share certain data segments, 


5e4el STANDARD STACK FRAME 


This section describes the standard stack frame which will 
be set up In conJdunction with the CALL instruction, The 
purpose of standardizing the stack frame ftayout is to 
provide common traceback and debugging Interfaces.» At the 
same timey allowance [Is made for a minimum frame for 
languages such as batch mode FORTRAN, with extensions for 
the complexity of languages such as PL/I. 


A stack frame consists of two areas; 


le The save are@ae 
2e The *“environmentai™ areas 


The save are@a belongs to the callers the "environmental" 
area belongs to the calilee and both exist in the 
appropriate rings. 


§e4e1.1 Icaceback 


Traceback is considered to be the lowest level of 
debugging and as such requires the support of both the 
loader and the compilers/assembler. Minimum traceback 
information will always be produced to facilitate some 
tracing from within the system. 


The compliters/assembler will produce traceback tables in 
the object module which correlate object=-code address of 
entry points and calls with source-code procedure names 
and tine numbers. The foader will maintain the relation 
of these object code addressese When traceback is 
required, these traceback tabiess pilus the stacks will be 
interpreted to give the source-code names and line numbers 
associated with the PVAs obtained during traceback. In 
full traceback mode entries will exist for each fine or 
source statement; in minimum traceback mode onty entry 
points and calis are monitored. 
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5.4.1.2 Static Chalo vs. Display 


(See Glossary for definitions.) 


It is not the Intention of this standard to dictate 
whether compiled code wili raference giobais via the 
static chain or a dispitay. Either is permitted and must 
be maintained by the software. Note? this only appliles to 
calis to a nested procedure and hence is intralanguage.e 


5e4e2 CHAINS OF ON-CONDITION PROCESSORS 


Software conventions for a standard on=-condition orocessor 
chain format are required to ensure that on-conditions can 
be processed correctly. 


The on-condition flag (OCF) in the save area Is used to 
indicate that the stack frame has associated on-condition 
processors. The first eight bytes of the stack frame 
(seointed te by the current stack frame (CSF) of the save 
area) are reserved for the head of the on=-condition 
processor chain. Ali object code generators must 
accommodate the head of chain reservation. If the OCF Is 
set In the save areas the eight bytes pointed to by CSF is 
the head of the on-condition processor chains If the OCF 
is not sets the contents of the eight bytes is undefined. 


5e%e3 DYNAMIC NON@=STACK STORAGE 


5242321 Dynamic Segments 


NOS/VE provides the capability of creating new segments 
during product execution. Since this increases the number 
of segments In active use and potentlialfy causes a 
performance degradations its use should be limited to 
situations where the alternatives are tess satisfactory. 
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524,32? Ejixed-Position Dynamic Storage 


The fundamental support for fixed-position dynamic storage 
allocation is provided by the CYBIL ALLOCATE statement 
with no IN option. 


Products coded In CYBIL and needing fixed=-position dynamic 
storage should use the ALLOCATE statement directly. 
Products not coded In CYBIL and needing fixed-position 
dynamic storage may either: 


1) include CY3IL subroutines containing the appropriate 
ALLOCATE statementss or 

2) use a set of common routines which will provide a CMM 
compatible interface to the ALLOCATE statement. 


304.323 Variable-Position Dynanic Storage 


Variable-position dynamic storage is not currently planned 
for support. 


505 COMMON SUPPORT MODULES 


This section wil! define modules which wil! be avallable 
for general use, 


Math Routines 


For a detailed account of the math routines to be provided 
see C180 Common Modules Math Library (CMML) ERS with DCS 
jog ID $2929. The routines will offer both a register 
calling sequence and the common calling sequence. Entry 
point names will meet the specifications of section 4.1.1. 


Numeric Conversion Routines 


Routines will be provided for all products (compller or 
runtime systems) to oerform numeric input and output 
conversion. This will ensure that the same numeric 
representation matches the same internal bit value by all 
processors. See also C180 common modules math Ilbrary 
(CMML) ERS with DCS tog ID S$29295 and CMML 
Assembly-languagea Support System ERS with OCS log ID $3410. 
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BDP* Unpacked Number= 
trailing 170 
sign 
combina- 
tion 
nondec.) hollerith 


. A 


Sb O Mer D he 
~~ DD 

~—D GT 3o 3 Om 

mM eg OF OY Tm 

oe py ee ODO) 


FROM 

Integer X X 

Real X(1) 

Longreal X(1) 

ASCII X X€L) X21) X€2) x 


ASCII X 
(nondec.) 


BDP* X 
Unpacked | X 

decimal 

trailing 

sign 

combined 

hollerith 


Number 170 x x 


*includes ali BDP types except: alphanumeric 


{1) there are additional routines for handling real and Jongreal conversions 
to and from ascli in olecemea!l fashion 


{2) translations moves etce 


Utilities 


A set of common utilities wlil be provided to carry out 
the foilowing Functions: 


* Diagnostic Handling ~- the formatting of diagnostic 


5-27 


CYBER 180 System Interface Standard 
ayia tres 


540 COMPILER AND ASSEMBLY CODE CONVENTIONS 
545 Sclinhictiy ede bende 


lines of output and the construction of the diagnostic 
listings. 


* Source listing formatting - the formatting of the 
source listing including output of the source lines to 
a print file, 


° Storage map/Attribute/Crass Reference listings — the 
formatting of this listing and output of its contents 
to a print File, 


* Comptier Usages Statistics - the generation of usage 
Statistics messagess 
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609 GLOSSABY_DE_TERMS 


in writing the System Interface Standard it became 
necessary to clarify the meaning of certain wordse This 
giossary contains those words which required 
clarification. The jist will be extended, 


“~a~ adjective 
“n= noun 
“y~ verb 


Binary ~a~ Of base 22 Not to be used without 
qualification to mean the object code 
output from a compiler. Note object 
code files are one of many different 
forms of binary files, 


Roolean “n= Data type which can hold the values 
Strue™ or "false™,. 


FCRTRAN “n= Roeolean data but required to occupy a 
Boolean full computer word. 
Diagnostic -n- Generally a part of a larger entitys 


such as fistable outputs, as opposed 
to an error messages which is 
generally a summary of a command. 
Diagnostics are generally Issued by a 
number of the product sets, such as a 
compiler. See also —- error messagee 
Example: A compiler may provide a 
stingie error message telling how many 
errors occurred during compilation 
and produce a diagnostic for each 
compilation error. 


Display “-n=- A mechanism for accessing gioba} 
variables of a program using a table 
of stack frame pointers; one pointer 
for each accessible scope and one 
table for each active scope. 


Error Message “~n- Generaliy a summary of a commands as 
opposed to a diagnostics which is 
generally a part of a larger entity» 
such as ftistable output. The error 
message is generally issued by the 
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operating system or by a product via 
the operating system. See also =- 
dlagnostic for an example, 

Invoke -v=- Applies only to spiritss witches,» 
etc. Procedures are called. 


Job Step ~n- A job step is the work done as a 
resuit of a single command in the job 
deck/file. Job steps execute 
sequentially within a job. 


Load Module “n= Object Information produced by object 
library generator and input to the 
loader or back into object Jibrary 
generator. Load modules are designed 
to facilitate processing by the 
loader. 


Qbject Module ~n- An object module is a unit containing 
code and/or data definition that is 
produced by compilers. 


Qbject Program -n- An object program is a set of object 
modules organized to perform some 
specific function (Ceeges compile 
COBOL statements). An object program 
Is prepared for execution by the 
loader, 


process(ing) —v- Comput{ing). Unrestricted to mean 
either hardware or software. 


Processor “n= Restricted to hardware CPU or PPU. 
May be used for software if 
sufficiently qualifieds e.g. language 
processors 


Product -n=- Any part of the standard software 
which is covered by the System 
Inerface Standard. 


Product Set n= That part of the System which is not 
part of the Operating Systeme 


record -n- A unit of data on a file. e@egs a 
card images line image. Not to be 
used without qualification if meaning 
a "CYBIL™ record or "SCL” record. 
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Standard “-n=- Plural-Standard not Standards when 


used in the sense of the System 
Interface standard, 


Static chain “-n- A mechanism for accessing global 
variables of a program using links 
through the stack frames, 

System “n= Ald products (aqeyv.) operating as a 
whole - to be distinguished from 
Qperating System, 


Task “n~ A task is an instance of execution of 
an object program. Multiple tasks 
can execute within a single Job 
step. Each task has its own address 
space (set of memory segments). 

Tasks may be initiated either 
synchronously or asynchronously to 
tre initiating taske. 
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